http://groups.google.com/group/comp.programming.threads?hl=en
comp.programming.threads@googlegroups.com
Today's topics:
* Why The Other Programs Don't Match Up! - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/65f54fabe8634895?hl=en
* my rwmutex algorithm for Linux... - 3 messages, 3 authors
http://groups.google.com/group/comp.programming.threads/t/61676475dbb8762b?hl=en
* Marketing Professional Seeking Apprentice! - 1 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/cc6b98f147c5d71c?hl=en
* Using a thread to complete object initialization - 2 messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/64cb03b37b5d9fea?hl=en
==============================================================================
TOPIC: Why The Other Programs Don't Match Up!
http://groups.google.com/group/comp.programming.threads/t/65f54fabe8634895?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, May 28 2009 11:14 am
From: B-Doe
Have you ever wondered why when you purchase most internet marketing
programs you never see profits? The reason is they never give you the
full package. They leave out the key ingredients to make your business
successful. Maverick's Money Making program truly is one of the best
I've ever seen. Hours of video training is included to help guide you
by almost putting you over the shoulder of a self-made millionaire. To
make the deal even better, there's even a 60 day money back guarantee!
Isn't that worth a better future for you or your family in today's
tough economy? So what are you waiting for? Visit the site below now
to change your life forever!
http://MavericksMoneyMakingNow.com - Click now while spots are still
avaliable!
==============================================================================
TOPIC: my rwmutex algorithm for Linux...
http://groups.google.com/group/comp.programming.threads/t/61676475dbb8762b?hl=en
==============================================================================
== 1 of 3 ==
Date: Fri, May 29 2009 2:19 am
From: Maxim Yegorushkin
On May 26, 7:38 pm, "Chris M. Thomasson" <n...@name.invalid> wrote:
> Here is a full example implementation:
>
> http://pastebin.com/f3d6140eb
>
> I have tested this on Fedore Core. However, it should compile on any IA32
> based system with GCC and PThreads (with support for `sem_post()'). If
> your having any troubles, please let me know.
>
> I am interested in hearing about the performance differences between the
> native PThread read/write mutex vs. my algorithm. Last time I checked the
> NPTL source code, it used internal mutexs for read access. Therefore, mine
> should have a performance "advantage".
Have you benchmarked it to validate your guesses?
--
Max
== 2 of 3 ==
Date: Fri, May 29 2009 11:10 am
From: "Chris M. Thomasson"
"Maxim Yegorushkin" <maxim.yegorushkin@gmail.com> wrote in message
news:a7c04724-895b-42de-bd66-a6f308e21670@r13g2000vbr.googlegroups.com...
On May 26, 7:38 pm, "Chris M. Thomasson" <n...@name.invalid> wrote:
> > Here is a full example implementation:
> >
> > http://pastebin.com/f3d6140eb
> >
> > I have tested this on Fedore Core. However, it should compile on any
> > IA32
> > based system with GCC and PThreads (with support for `sem_post()'). If
> > your having any troubles, please let me know.
> >
> > I am interested in hearing about the performance differences between the
> > native PThread read/write mutex vs. my algorithm. Last time I checked
> > the
> > NPTL source code, it used internal mutexs for read access. Therefore,
> > mine
> > should have a performance "advantage".
> Have you benchmarked it to validate your guesses?
Not yet. However, if the implmentation is anything like:
http://www.opensource.apple.com/source/Libc/Libc-498/pthreads/pthread_rwlock.c
or glibc ver 2.10.1 which has code like:
/* Acquire read lock for RWLOCK. */
int
__pthread_rwlock_rdlock (rwlock)
pthread_rwlock_t *rwlock;
{
int result = 0;
/* Make sure we are along. */
lll_lock (rwlock->__data.__lock, rwlock->__data.__shared);
[...]
}
Then, my algorithm should outperform them because if multiple reader threads
hit those implementations above, they will all be contending for the single
mutex. On the other hand, my algorithm will allow the readers to gain
wait-free bounded-time access. Also, my algorithm is 100% starvation free.
I will code up a little test to see if my algorithm as any performance
enhancements on my Fedora Core installation. It should be ready sometime
today. I think I will set it up as a single linked list with multiple
readers iterating over it as fast as they can, and a couple of writers that
periodically add/remove items. I will calculate how many iterations
per-reader-thread-per-second are achieved.
== 3 of 3 ==
Date: Fri, May 29 2009 12:54 pm
From: "Chris M. Thomasson"
On Fri, 29 May 2009 02:19:37 -0700, Maxim Yegorushkin wrote:
> On May 26, 7:38 pm, "Chris M. Thomasson" <n...@name.invalid> wrote:
>> Here is a full example implementation:
>>
>> http://pastebin.com/f3d6140eb
>>
>> I have tested this on Fedore Core. However, it should compile on any
>> IA32 based system with GCC and PThreads (with support for
>> `sem_post()'). If your having any troubles, please let me know.
>>
>> I am interested in hearing about the performance differences between
>> the native PThread read/write mutex vs. my algorithm. Last time I
>> checked the NPTL source code, it used internal mutexs for read access.
>> Therefore, mine should have a performance "advantage".
>
> Have you benchmarked it to validate your guesses?
Here is a VERY CRUDE test program:
This mainly tests read performance. Writes are VERY few and far between.
So writer-to-reader contention will probably never show up. Anyway, here
is the command line I used to compile my version:
gcc -Wall -pedantic -DNDEBUG -O3 rwmutex.c -lpthread
And here is the one I used for the NPTL:
gcc -Wall -pedantic -DNDEBUG -DUSE_PTHREAD_NATIVE_RWLOCK -O3 rwmutex.c -lpthread
Here is the relevant portion of the output I get from my version:
TEST RUN 1 of 2 RUNNING...
READERS ACHIEVED 249999 ITERATIONS PER-THREAD-PER-SECOND
TEST RUN 1 of 2 COMPLETED!!!
------------------------------------
TEST RUN 2 of 2 RUNNING...
READERS ACHIEVED 249999 ITERATIONS PER-THREAD-PER-SECOND
TEST RUN 2 of 2 COMPLETED!!!
------------------------------------
And here is the output I get from the NPTL version:
TEST RUN 1 of 2 RUNNING...
READERS ACHIEVED 133333 ITERATIONS PER-THREAD-PER-SECOND
TEST RUN 1 of 2 COMPLETED!!!
------------------------------------
TEST RUN 2 of 2 RUNNING...
READERS ACHIEVED 133333 ITERATIONS PER-THREAD-PER-SECOND
TEST RUN 2 of 2 COMPLETED!!!
------------------------------------
As you can see, my version is getting 116666 more reads per-second-per-
thread. AFAICT, that is fairly significant.
==============================================================================
TOPIC: Marketing Professional Seeking Apprentice!
http://groups.google.com/group/comp.programming.threads/t/cc6b98f147c5d71c?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, May 29 2009 10:31 am
From: Brandon Noe
Sitting there wondering how your going to pay your bills? Tired of
living paycheck to paycheck? Then boy do I have the answer for you!
Self-made Millionaire is revealing his Wealth making blueprint to a
select few. You know what else it even comes with a "Make Money or
its Free" guarantee which makes this offer out of this world. What are
you waiting for join the society today and change your future not only
for yourself but for your family!
http://MavericksMoneyMakingNow.com
==============================================================================
TOPIC: Using a thread to complete object initialization
http://groups.google.com/group/comp.programming.threads/t/64cb03b37b5d9fea?hl=en
==============================================================================
== 1 of 2 ==
Date: Fri, May 29 2009 10:45 am
From: "Chris M. Thomasson"
"vl106" <vl106@hotmail.com> wrote in message
news:785dtvF1k4nfnU1@mid.uni-berlin.de...
>I have the following problem: a function shall return a complex object. The
>caller
> shall receive the object immediately (e.g. without blocking). The real
> initialization
> is done by a worker thread (as being time-consuming). I came up with the
> following
> solution. Any better ideas?
> [...]
Something like the following quick pseudo-code:
______________________________________________________________________
void worker_threads();
class future {
HANDLE m_event; // manual-reset event set to false
virtual void compute() = 0;
void prv_complete() {
compute();
SetEvent(m_event);
}
friend void worker_threads();
public:
void wait() {
WaitForSingleObject(m_event, INFINITE);
}
};
static thread_safe_queue<future*> g_future_queue;
void worker_threads() {
for (;;) {
g_future_queue.pop_wait()->prv_complete();
}
}
void foo() {
class computation : public future {
int m_value;
void compute() {
// lengthy processing
m_value = 123;
}
void whatever() {
g_future_queue.push(this);
wait();
// `m_value' is now ready
}
};
computation c;
c.whatever();
}
______________________________________________________________________
?
== 2 of 2 ==
Date: Fri, May 29 2009 2:52 pm
From: "Chris M. Thomasson"
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:eyVTl.121693$3k7.15720@newsfe17.iad...
> "vl106" <vl106@hotmail.com> wrote in message
> news:785dtvF1k4nfnU1@mid.uni-berlin.de...
>>I have the following problem: a function shall return a complex object.
>>The caller
>> shall receive the object immediately (e.g. without blocking). The real
>> initialization
>> is done by a worker thread (as being time-consuming). I came up with the
>> following
>> solution. Any better ideas?
>> [...]
>
> Something like the following quick pseudo-code:
> ______________________________________________________________________
> void worker_threads();
>
>
> class future {
> HANDLE m_event; // manual-reset event set to false
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Should probably just use an automatic reset event here. Unless you want to
allow multiple threads to wait on a single future. However, then some "reset
event logic" would need to be implemented. I would advise you to just use
the automatic event, and only allow a single thread to wait on a future
object...
> [...]
> ______________________________________________________________________
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.programming.threads"
group.
To post to this group, visit http://groups.google.com/group/comp.programming.threads?hl=en
To unsubscribe from this group, send email to comp.programming.threads+unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.programming.threads/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment