Linux pthread_cond_broadcast waking only one thread out of four waiting
theosib
version is 2.8. I'm having a problem where pthread_cond_broadcast
only wakes one of the threads that is waiting on a given signal.
The relevant code is at the bottom. I have four worker threads. Each
takes its own lock and calls pthread_cond_wait on a common condition
variable. The manager thread calls pthread_cond_broadcast on that
common CV, which should wake all the worker threads. Unfortunately,
only one of the worker threads wakes up. Note that if I replace the
call to broadcast with four calls to signal, it works fine.
Can anyone give me some tips on what I might be doing wrong? Does the
CV need to be initialized differently? I think the mutexes used by
the worker threads aren't important, but could that be causing a
problem? Each one has its own lock, so they can't be interfering with
each other.
Thanks!
The debug output I get is:
forward_h_worker 0 enter
forward_h_worker 0 sleep
forward_h_worker 1 enter
forward_h_worker 1 sleep
forward_h_worker 2 enter
forward_h_worker 2 sleep
forward_h_worker 3 enter
forward_h_worker 3 sleep
forward_h_manager enter
forward_h_manager broadcast
forward_h_worker 0 wake
forward_h_manager wait
forward_h_worker 0 sleep
void forward_h_group(float *inputs, float *outputs, h_weights_t
*h_weights,
int group)
{
int i, s, e;
s = group * 250;
e = group * 250 + 250;
for (i=s; i<e; i++) {
outputs[i] = sigmoid(dotprod1000sse2(inputs, h_weights[i]));
}
}
typedef struct {
float *inputs;
float *outputs;
h_weights_t *h_weights;
} forward_h_task_t;
pthread_t forward_h_thread[4];
volatile int forward_h_work_counter;
pthread_mutex_t forward_h_lock[4], forward_h_lock_counter;
pthread_cond_t forward_h_cond_worker, forward_h_cond_manager;
forward_h_task_t forward_h_task;
void *forward_h_worker(void *in)
{
int group = (int)in;
printf("forward_h_worker %d enter\n", group);
pthread_mutex_lock(&forward_h_lock[group]);
for (;;) {
printf("forward_h_worker %d sleep\n", group);
pthread_cond_wait(&forward_h_cond_worker,
&forward_h_lock[group]);
printf("forward_h_worker %d wake\n", group);
forward_h_group(forward_h_task.inputs,
forward_h_task.outputs,
forward_h_task.h_weights, group);
pthread_mutex_lock(&forward_h_lock_counter);
if (--forward_h_work_counter == 0) {
printf("forward_h_worker %d signal manager\n", group);
pthread_cond_signal(&forward_h_cond_manager);
}
pthread_mutex_unlock(&forward_h_lock_counter);
}
}
void forward_h_manager(float *inputs, float *outputs, h_weights_t
*h_weights)
{
int i;
printf("forward_h_manager enter\n");
pthread_mutex_lock(&forward_h_lock_counter);
forward_h_task.inputs = inputs;
forward_h_task.outputs = outputs;
forward_h_task.h_weights = h_weights;
forward_h_work_counter = 4;
printf("forward_h_manager broadcast\n");
pthread_cond_broadcast(&forward_h_cond_worker);
//for (i=0; i<4; i++) {
// pthread_cond_signal(&forward_h_cond_worker);
//}
printf("forward_h_manager wait\n");
pthread_cond_wait(&forward_h_cond_manager,
&forward_h_lock_counter);
pthread_mutex_unlock(&forward_h_lock_counter);
printf("forward_h_manager exit\n");
}
void forward_h_init()
{
int i;
pthread_cond_init(&forward_h_cond_worker, NULL);
pthread_cond_init(&forward_h_cond_manager, NULL);
for (i=0; i<4; i++) {
pthread_mutex_init(&forward_h_lock[i], NULL);
}
for (i=0; i<4; i++) {
pthread_create(&forward_h_thread[i], NULL, forward_h_worker,
(void *)i);
}
}
David Schwartz
> The relevant code is at the bottom. I have four worker threads. Each
> takes its own lock and calls pthread_cond_wait on a common condition
> variable. The manager thread calls pthread_cond_broadcast on that
> common CV, which should wake all the worker threads. Unfortunately,
> only one of the worker threads wakes up. Note that if I replace the
> call to broadcast with four calls to signal, it works fine.
> Can anyone give me some tips on what I might be doing wrong? Does the
> CV need to be initialized differently? I think the mutexes used by
> the worker threads aren't important, but could that be causing a
> problem? Each one has its own lock, so they can't be interfering with
> each other.
Whoa! If each thread has its own lock, then they can definitely be
interfering with each other. It's the fact that they must hold the
*SAME* lock that ensures that they don't interfere with each other. By
giving each thread its own lock, you have no synchronization at all!
The whole point of the lock is to synchronize access to whatever the
condvar protects.
DS
David Schwartz
You have lots more bugs. I'll point a few of them out:
Oops, you called pthread_cond_wait without checking
forward_h_work_counter first. How do you know you need to wait?
If this wait is waiting for a different predicate on the same
condition variable, you may get into trouble. I wouldn't advise using
the same cond var for more than one predicate unless you *really*
understand cond vars.
> pthread_mutex_unlock(&forward_h_lock_counter);
> printf("forward_h_manager exit\n");
>
> }
> void forward_h_init()
> {
> int i;
>
> pthread_cond_init(&forward_h_cond_worker, NULL);
> pthread_cond_init(&forward_h_cond_manager, NULL);
>
> for (i=0; i<4; i++) {
> pthread_mutex_init(&forward_h_lock[i], NULL);
> }
>
> for (i=0; i<4; i++) {
> pthread_create(&forward_h_thread[i], NULL, forward_h_worker,
> (void *)i);
> }
>
> }
Here is the correct pattern for using pthread_cond_wait:
1) Acquire the mutex that protects the predicate.
2) Check if the predicate is true, if so skip to step 5.
3) Block on the cond var, releasing the mutex.
4) Go to step 2.
5) Do whatever you need to do.
6) Either release the mutex or jump to step 2, depending on what
you're trying to do.
In terms of your program, that's:
pthread_mutex_lock(&forward_h_lock_counter);
while(forward_h_work_counter==0) // or >0, it's not clear what you're
trying to wait for
pthread_cond_wait(&forward_h_cond_manager, &forward_h_lock_counter);
...
Notice that you must acquire the mutex that protects the predicate
(forward_h_work_counter in this case). And you must test it *before*
you call pthread_cond_wait. And you must loop in case the predicate is
no longer true by the time you get around to running again.
Contrary to its name, pthread_cond_wait is not a conditional wait.
It's an unconditional wait *for* a condition.
DS
theosib
I do not want to sync the threads. They are doing independent work.
The idea is for the manager to wake up the worker threads (on an SMP
machine), the manager to go to sleep, and then the manager to wake up
when the last worker has finished.
theosib
> On Aug 25, 8:25 pm, theosib <theo...@gmail.com> wrote:
>
> You have lots more bugs. I'll point a few of them out:
Thank you!
> > void *forward_h_worker(void *in)
> > {
> > int group = (int)in;
>
> > printf("forward_h_worker %d enter\n", group);
> > pthread_mutex_lock(&forward_h_lock[group]);
>
> > for (;;) {
> > printf("forward_h_worker %d sleep\n", group);
> > pthread_cond_wait(&forward_h_cond_worker,
>
> Oops, you called pthread_cond_wait without checking
> forward_h_work_counter first. How do you know you need to wait?
You mean in the manager thread? Good point. However, there are two
reasons why this doesn't affect me yet. One is that I'm holding the
lock on the counter in the manager up until the point where it sleeps
on forward_h_cond_manager, and secondly, the failed broadcast happens
on the FIRST pass through all of this. I'll fix this, but it won't
fix the broadcast problem.
> > printf("forward_h_manager broadcast\n");
> > pthread_cond_broadcast(&forward_h_cond_worker);
> > //for (i=0; i<4; i++) {
> > // pthread_cond_signal(&forward_h_cond_worker);
> > //}
> > printf("forward_h_manager wait\n");
> > pthread_cond_wait(&forward_h_cond_manager,
> > &forward_h_lock_counter);
>
> If this wait is waiting for a different predicate on the same
> condition variable, you may get into trouble. I wouldn't advise using
> the same cond var for more than one predicate unless you *really*
> understand cond vars.
Which cond variable are you referring to? Plus, I don't know how to
send signals otherwise.
The manager is using only one mutex.
The worker threads are each using a different mutex, but with the same
condition variable. If they were to use the same mutex, then that
would serialize them, no? I want them all to wake up, and when the
last one goes to sleep, the manager wakes up. Is there a better way
to do this?
>
> Here is the correct pattern for using pthread_cond_wait:
>
> 1) Acquire the mutex that protects the predicate.
> 2) Check if the predicate is true, if so skip to step 5.
> 3) Block on the cond var, releasing the mutex.
> 4) Go to step 2.
> 5) Do whatever you need to do.
> 6) Either release the mutex or jump to step 2, depending on what
> you're trying to do.
>
> In terms of your program, that's:
>
> pthread_mutex_lock(&forward_h_lock_counter);
> while(forward_h_work_counter==0) // or >0, it's not clear what you're
> trying to wait for
> pthread_cond_wait(&forward_h_cond_manager, &forward_h_lock_counter);
> ...
>
> Notice that you must acquire the mutex that protects the predicate
> (forward_h_work_counter in this case). And you must test it *before*
> you call pthread_cond_wait. And you must loop in case the predicate is
> no longer true by the time you get around to running again.
Ok, so I have already taken the mutex as you describe. I just didn't
check the counter. I can see why that's important, but what this
fixes is problems with the manager not going to sleep. The problem
I'm encountering is that the worker threads don't wake up.
>
> Contrary to its name, pthread_cond_wait is not a conditional wait.
> It's an unconditional wait *for* a condition.
Yeah, I understand it as "sleep until you get the signal."
Thanks for your help. I'm still kinda lost, though. I'll make the
changes you suggest, but I'm still having the problem of not having
the workers (except one) wake up in the first place.
Hallvard B Furuseth
> I do not want to sync the threads. They are doing independent work.
> The idea is for the manager to wake up the worker threads (on an SMP
> machine), the manager to go to sleep, and then the manager to wake up
> when the last worker has finished.
pthread_cond_wait() requires multiple threads that wait for the same
cond, to also pass the same mutex to pthread_cond_wait(). That mutex
should be protecting some expression which says whether or not to finish
the wait. You must at least sync reads in the worker threads of that
expression, with changes to that expression in the manager thread:
The manager thread locks that mutex to change the expression and
signal/broadcast the cond, and the workers lock it to check the
expression and wait.
Also note that pthread_cond_wait() can have spurious wakeups,
i.e. the thread can wake up even though it was not signalled.
So the correct use of pthread_cond_wait is normally like this:
while (! something_to_do)
pthread_cond_wait(&cv, &todo_mutex);
where the manager thread will lock &todo_mutex, modify something_to_do,
signal/broadcast cv, and unlock the mutex.
--
Hallvard
David Schwartz
> Ok, so I have already taken the mutex as you describe. I just didn't
> check the counter. I can see why that's important, but what this
> fixes is problems with the manager not going to sleep. The problem
> I'm encountering is that the worker threads don't wake up.
They don't wake up for two reasons. First, they aren't holding the
mutex that protects the condition variable, thus corrupting the
condition variable. Second, they are going to sleep when they
shouldn't, because they don't check whether they should go to sleep or
not.
> Thanks for your help. I'm still kinda lost, though. I'll make the
> changes you suggest, but I'm still having the problem of not having
> the workers (except one) wake up in the first place.
Because you don't synchronize your threads. They're all holding
different mutexes, and so there's no mutex that protects the predicate
and condition variable. So they stomp all over each other and corrupt
the condition variable.
Let me ask you a simple question -- the condition variable itself is
shared by the thread. What mutex protects it from concurrent access
that might corrupt it?
DS
David Schwartz
> I do not want to sync the threads.
Well then what do you expect? They fail to act in a coordinated manner
because you have made no effort to synchronize them. They go to sleep
when they feel like it, wake up threads when they feel like, stomp on
the condition variable without holding the mutex that protects it --
pure chaos.
> They are doing independent work.
No, they are not. They are blocking on and waking on the same
condition variable. There is only one condition variable and only one
count variable that is shared by all the threads.
> The idea is for the manager to wake up the worker threads (on an SMP
> machine), the manager to go to sleep, and then the manager to wake up
> when the last worker has finished.
It's very tricky to use one condition variable for two predicates. I
would strongly advise you to make two condition variables, one for
"last worker finished" and one for "there is work to be done". (It can
be done, but it's easy to mess it up in strange and subtle ways.)
DS
David Schwartz
By the way, this is the pattern you want:
Worker Thread:
1) Take work mutex.
2) While there is no work, block on the 'work to do' condition
variable (thus releasing the mutex).
3) Take a job.
4) Release the work mutex.
5) Do the job.
6) Take work mutex.
7) Signal the 'work is done' cond var. (If desired, signal only if
some count of outstanding jobs goes to zero.)
8) Go to step 2.
Manager thread:
1) Take work mutex.
2) Queue jobs.
3) Broadcast 'work to do' cond var (can be done before step 3).
- you can now release the work mutex, do other things, go back to step
1 to queue more jobs, but at the end, reacquire the work mutex -
4) While the work is not all done, block on the 'work is done'
condition variable (thus releasing the mutex).
5) Release work mutex
DS
theosib
wrote:
That fixed it. It never would have occurred to me that all of the
waits have to hang on the same lock. The man pages don't mention it,
and none of the online tutorials I've read have said anything about
it.
Somewhat related question: What is the overhead involved here? I
took an algorithm that goes through several million instructions and
divided it up so that the work could be spread across processors.
It's now slower. It could be cache effects, I don't think is an issue
here. Is the overhead of this wakeup mechanism so horrible that it's
worse than millions of instructions?
Thanks!
Hallvard B Furuseth
> On Aug 26, 8:46 am, Hallvard B Furuseth <h.b.furus...@usit.uio.no>
> wrote:
> It never would have occurred to me that all of the waits have to hang
> on the same lock. The man pages don't mention it, and none of the
> online tutorials I've read have said anything about it.
You can read the posix spec online here:
http://www.unix.org/version3/online.html
I don't know Gentoo, but the RedHat manpages have copied this from Posix:
"The effect of using more than one mutex for concurrent
pthread_cond_timedwait() or pthread_cond_wait() operations on the
same condition variable is undefined; that is, a condition variable
becomes bound to a unique mutex when a thread waits on the condition
variable, and this (dynamic) binding shall end when the wait returns."
It should have been natural to think of it anyway, though. Signalling
a condition variable means to notify a thread which is waiting for some
boolean expression to become true, that it's time to check if that
expression now has become true. So normally you signal or broadcast
on it every time you change the value of that expression from false to
true, which again means that both sides need to have the same mutex
locked, protecting the variables used in that expression.
> Somewhat related question: What is the overhead involved here?
I don't know, but:
> I took an algorithm that goes through several million instructions and
> divided it up so that the work could be spread across processors.
> It's now slower. It could be cache effects, I don't think is an issue
> here. Is the overhead of this wakeup mechanism so horrible that it's
> worse than millions of instructions?
Well, if you've got one single-core processor and the task is purely
CPU-bound (no operations that block), then of course you'll get a
slowdown for the extra context switches if you split it up in threads.
Assuming that's not the case though:
You could be making some mistake like keeping a mutex locked too long,
so other threads must wait for it. Have a look at the output from "top"
or "uptime" and see how busy the CPUs are. (I don't remember how to
interpret it with multiple CPUs though, hopefully the manpages say...)
Or you might have a programming error with your threading - so you
should check the return codes from your thread calls. Maybe just wrap
the calls these macros (using gcc extensions):
#include <assert.h>
#define EZ(res) (__extension__({int rES=(res); assert(rES == 0);}))
#define EP(res) (__extension__({int rES=(res); assert(rES >= 0);}))
EZ() expects zero for success, EP() nonnegative. Combine that with
initializing the mutexes to error-checking mutexes, see
pthread_mutexattr_init + pthread_mutexattr_settype with type
PTHREAD_MUTEX_ERRORCHECK (or maybe PTHREAD_MUTEX_ERRORCHECK_NP for Gnu
systems).
As for things like cache problems, it depends on what you know about how
your hardware and compiler works. For example, consider this:
void sum(double *resultp, const double x[], const double y[]) {
*resultp = 0;
for (int i = 0; i < 10000; i++)
*resultp += x[i] * y[i];
}
I've seen code like that recently. Well, more complex, but anyway:
- presumably resultp doesn't point into x or y - but the compiler
doesn't know that, so it cannot optimize by assuming the assignments
to *resultp won't update x and y.
The consts doen't help. "restrict" from C99 does though.
- if you are running 10 such threads, with resultp pointing into an
array of 10 results, then there is no overlap between the resultp
variables but you still get a lot of cache waits because a cache line
contains a _chunk_ of memory. So one thread updates results[0], and
then the thread waiting to access result[1]s in the same cache line
must wait anyway. Assuming the hardware ensures memory coherence
between multiple caches, that is. Posix doesn't guarantee that,
except at mutex/cond calls and some other cases.
Anyway, the fix is of course to keep the result in a local double and
write to resultp at the end. Which gives fewer pointer accesses too.
--
Hallvard
David Schwartz
> That fixed it. It never would have occurred to me that all of the
> waits have to hang on the same lock. The man pages don't mention it,
> and none of the online tutorials I've read have said anything about
> it.
It is impossible to use a condition variable any other way, for two
reasons:
1) All threads that access any shared resource always must do so under
protection of the same mutex. Otherwise, the POSIX rule against
concurrent writes to the same object specifies that there are
unpredictable results.
2) Unless they all hold the same mutex, there is no way they can make
the decision to block on the condition variable. The whole point of
pthread_cond_wait is to atomically release the mutex that protects the
predicate and block. If there's no 'the mutex that protects the
predicate', then there's no reason to call pthread_cond_wait.
> Somewhat related question: What is the overhead involved here? I
> took an algorithm that goes through several million instructions and
> divided it up so that the work could be spread across processors.
> It's now slower. It could be cache effects, I don't think is an issue
> here. Is the overhead of this wakeup mechanism so horrible that it's
> worse than millions of instructions?
The condition variable mechanism is very light. Odds are you're seeing
the algorithm run slower because of either false sharing, excessive
real sharing, or some kind of coding error (such as holding a mutex
too long).
DS
Szabolcs Ferenczi
1. You could have detected your condition variable usage problem with
the simple condition variable test:
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/0ff7ac10adadee22#
2. Your should align the usage of mutexes, condition variables, and
the protected resources.
3. You should consider using simple semaphores for event signaling
(which is your problem to solve) instead of the more complicated
mutex---condition variable pairs which are not designed for this task.
Best Regards,
Szabolcs
Chris M. Thomasson
news:ebdf4ebd-8d63-4a71-82e4-> 3f54ee...@f63g2000hsf.googlegroups.com...
> I have three remarks:
> 1. You could have detected your condition variable usage problem with
> the simple condition variable test:
> http://groups.google.com/group/comp.programming.threads/browse_frm/thread/0ff7ac10adadee22
Use Relacy.
> 2. Your should align the usage of mutexes, condition variables, and
> the protected resources.
You mean align the internal data-structures which make up dais
condvars/mutexs?
> 3. You should consider using simple semaphores for event signaling
> (which is your problem to solve) instead of the more complicated
> mutex---condition variable pairs which are not designed for this task.
Ummm, sorry. You fail to understand that condvar/mutex can be used for event
signaling. We have been over this before.
David Schwartz
wrote:
> 3. You should consider using simple semaphores for event signaling
> (which is your problem to solve) instead of the more complicated
> mutex---condition variable pairs which are not designed for this task.
I see you're still dishing out the bogus advice to anyone dumb enough
to listen to you. Since you know that this is your own personal view
and that everybody else, people who use this stuff every day, hold
precisely the opposite view, I can only understand this as malicious.
You don't tell someone setting out for the first time on his new boat
that he should take lead life preservers. Even if you think he should,
you know that nobody else agrees with you, and it's not your place to
spout views that nobody else agrees with as if they were obvious.
You are welcome to believe whatever you want to believe. But to tell
someone who doesn't know any better your own crazy personal view, that
nobody else on the planet shares, as if it was what a beginner should
learn, well, that's just plain evil.
DS
Szabolcs Ferenczi
> "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
> > 2. Your should align the usage of mutexes, condition variables, and
> > the protected resources.
>
> You mean align the internal data-structures which make up dais
> condvars/mutexs?
No, I do not mean nonsense.
> > 3. You should consider using simple semaphores for event signaling
> > (which is your problem to solve) instead of the more complicated
> > mutex---condition variable pairs which are not designed for this task.
>
> Ummm, sorry. You fail to understand that condvar/mutex can be used for event
> signaling. We have been over this before.
You can be sorry, indeed, that is right. Who told you that mutex and
condition variable cannot be used for event signaling? The matter of
fact is that it can be used, however, it must pass the condition
variable test:
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/0ff7ac10adadee22
On the other hand, for event signaling the semaphore is more simple
and more safe to use.
Besides, you can use mutex and condition variable for event signaling
iff you build a semaphore out of them. But why should anyone building
it if it is available? Simply use the right programming tool for each
problem. That is it, my young friend.
Cheers,
Szabolcs
Szabolcs Ferenczi
> On Aug 27, 12:39 am, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
> wrote:
>
> > 3. You should consider using simple semaphores for event signaling
> > (which is your problem to solve) instead of the more complicated
> > mutex---condition variable pairs which are not designed for this task.
>
> I see you're still dishing out the bogus advice to anyone dumb enough
It might seem "bogus advice" to you since you apparently miss some
basic education in concurrent programming. Check out some basic course
books instead of jumping on every post of mine like a monkey.
Try to refrain yourself, buddy.---Please.
Best Regards,
Szabolcs
David Schwartz
wrote:
> books instead of jumping on every post of mine like a monkey.
A little paranoid?
DS
Chris M. Thomasson
On Aug 28, 2:45 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
>
> > > 2. Your should align the usage of mutexes, condition variables, and
> > > the protected resources.
> >
> > You mean align the internal data-structures which make up dais
> > condvars/mutexs?
> No, I do not mean nonsense.
> > > 3. You should consider using simple semaphores for event signaling
> > > (which is your problem to solve) instead of the more complicated
> > > mutex---condition variable pairs which are not designed for this task.
> >
> > Ummm, sorry. You fail to understand that condvar/mutex can be used for
> > event
> > signaling. We have been over this before.
> You can be sorry, indeed, that is right. Who told you that mutex and
> condition variable cannot be used for event signaling?
You have tried to convince this group on multiple occasions that a condvar
cannot be used for event signaling. Its nice to see that you finally
realized that your initial conclusions were all wrong.
BTW, did you know when I write the word condvar, it automatically implies
that a mutex must be used as well? Sometimes I think you don't understand
that fact. You seem to think of condvar and mutex as separate, when the
condvar interface directly ties them together. Anytime somebody says
condvar, the use of a mutex is virtually a given. You make a fool out of
yourself when you say that a condvar cannot be used for event signaling.
Period.
> The matter of
> fact is that it can be used, however, it must pass the condition
> variable test:
> http://groups.google.com/group/comp.programming.threads/browse_frm/thread/0ff7ac10adadee22
> On the other hand, for event signaling the semaphore is more simple
> and more safe to use.
More simple and safe? You don't know what the heck your talking about. To
prove this, well, please show me how to efficiently broadcast events using a
semaphore and honor the proper wakeup semantics what a condvar has, and how
waiting on a semaphore in the presence of signals is easier than using a
condvar?
Did you know that a condvar has certain wakeup properties that a semaphore
simply does not have?
> Besides, you can use mutex and condition variable for event signaling
> iff you build a semaphore out of them.
lol; you don't need to build a semaphore out of a condvar. You can use
events within the data-structure itself as a PREDICATE; this is beginner
stuff that you don't seem to be able to understand:
http://groups.google.com/group/comp.programming.threads/msg/59aa60b5ab4c2ea2
I suggest you read all of that; then read it again. Then buy David Butenhofs
excellent book and read it a couple of times. I know that you called him a
fool and a clown; buy his book anyway. You don't know what your missing!
> But why should anyone building
> it if it is available? Simply use the right programming tool for each
> problem. That is it, my young friend.
You don't know how to use complex predicates. That's your problem, not the
condvars...
Szabolcs Ferenczi
> "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
>
> news:f18cd37b-08cc-4d9a...@m45g2000hsb.googlegroups.com...
> On Aug 28, 2:45 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
>
> > > "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
>
> > > > 2. Your should align the usage of mutexes, condition variables, and
> > > > the protected resources.
>
> > > You mean align the internal data-structures which make up dais
> > > condvars/mutexs?
> > No, I do not mean nonsense.
> > > > 3. You should consider using simple semaphores for event signaling
> > > > (which is your problem to solve) instead of the more complicated
> > > > mutex---condition variable pairs which are not designed for this task.
>
> > > Ummm, sorry. You fail to understand that condvar/mutex can be used for
> > > event
> > > signaling. We have been over this before.
> > You can be sorry, indeed, that is right. Who told you that mutex and
> > condition variable cannot be used for event signaling?
>
> You have tried to convince this group on multiple occasions that a condvar
> cannot be used for event signaling.
That is right, a condition variable is not designed for that. It is
only designed to optimise a busy waiting loop in terms of processor
cycles. Check some basic concurrent programming literature if you do
not know this basic stuff. I have already provided pointers for you
and for the other beginners. Look it up.
> Its nice to see that you finally
> realized that your initial conclusions were all wrong.
You can use a combination of mutex and condition variable where you
implement a construction that in effect is a semaphore. Then you can
use it for event signalling.
> BTW, did you know when I write the word condvar, it automatically implies
> that a mutex must be used as well?
It shoud be so but it is not evident for newcommers like you and your
beloved masters.
> Sometimes I think you don't understand
> that fact.
You may think so but you are in error as usual. You simply
misunderstand things due to lack of education in concurrent
programming. When I use the terminology, self trained guys like you
and your buddy misunderstand it.
> You seem to think of condvar and mutex as separate, when the
> condvar interface directly ties them together. Anytime somebody says
> condvar, the use of a mutex is virtually a given. You make a fool out of
> yourself when you say that a condvar cannot be used for event signaling.
> Period.
Try to use it for event signalling. Your big talk master failed to do
his homework anyway. Period.
> > The matter of
> > fact is that it can be used, however, it must pass the condition
> > variable test:
> >http://groups.google.com/group/comp.programming.threads/browse_frm/th...
> > On the other hand, for event signaling the semaphore is more simple
> > and more safe to use.
>
> More simple and safe?
That is it. You slowly learn something.
> You don't know what the heck your talking about.
I am talking about basic facts that you could learn in the first year
if you were taken any course in concurrent programming.
> To
> prove this, well, please show me how to efficiently broadcast events using a
> semaphore and honor the proper wakeup semantics what a condvar has, and how
> waiting on a semaphore in the presence of signals is easier than using a
> condvar?
semaphore s;
...
s.V();
> Did you know that a condvar has certain wakeup properties that a semaphore
> simply does not have?
Yes. Spurious wakeup. That is why you and your master will fail if you
are trying to demonstrate how you use the condition variable for event
signalling.
It means that whenever a condition variable wait operation returns for
you, you can have no idea whether a signal happened or a spurious
wakeup. Hence the event is communicated via the shared variables and
not by the condition variable (which were originally called queueing
variable). You need the mutex to safely check the state of the shared
variables in a busy loop and the conditon variable alias queueing
variable is just an optimisation tool. It allows you to check the
state of the shared variables less frequently. That is why any correct
algorithm must work if you substitute the condition variable wait
operation with a mutex unlock-lock pair.
You and your masters seem to be not aware of that.
> > Besides, you can use mutex and condition variable for event signaling
> > iff you build a semaphore out of them.
>
> lol; you don't need to build a semaphore out of a condvar.
Whether you like it or not, if you try to implement the construction
for an event signalling, you will end up with the functionality of the
semaphore. Try it my young friend and you will see.
> You can use
> events within the data-structure itself as a PREDICATE; this is beginner
> stuff that you don't seem to be able to understand:
This is a beginner misconception which is not surprising in your side.
It is not any predicate but shared variables. What you call predicate
is an expression with shared variables in it.
> .... Then buy David Butenhofs
> excellent book and read it a couple of times.
First he must do his homework. He had a big face talking about
something he cannot do. At least so far he failed to do. And it is not
an accident.
> I know that you called him a
> fool
I never called him a fool. You did that several times.
> and a clown;
He is one of them since he made himself one.
> buy his book anyway.
I do not spend my money on outdated stuff. Especially if the author
made a clown of himself.
> You don't know what your missing!
I know his errors and that I am never missing.
> > But why should anyone building
> > it if it is available? Simply use the right programming tool for each
> > problem. That is it, my young friend.
>
> You don't know how to use complex predicates. That's your problem, not the
> condvars...
Predicates are complex for you apparently.
Period.
Calm down young friend.
Best Regards,
Szabolcs
David Schwartz
wrote:
> That is right, a condition variable is not designed for that. It is
> only designed to optimise a busy waiting loop in terms of processor
> cycles.
You are quite possibly the only person who believes this, and the
claim is absurd on its face. It's like saying that airplanes are
designed to optimize bicycle speed by removing the pedaling.
You've constructed a hypothetical structure (a busy waiting loop) that
has nothing to do with a condition variable and said, "Look! A
condition variable is better than that! Therefore, a condition
variable was invented to optimize that."
> Check some basic concurrent programming literature if you do
> not know this basic stuff. I have already provided pointers for you
> and for the other beginners. Look it up.
The only thing worse than a misguided ignorant fool is an obnoxious,
self-righteous, misguided ignorant fool.
> You can use a combination of mutex and condition variable where you
> implement a construction that in effect is a semaphore. Then you can
> use it for event signalling.
In other words, you can use a condition variable for signaling. Guess
what? This is precisely the kind of thing condition variables were
invented for.
Now that's a particularly bad way to use a condition variable for
signaling, because it replicated the predicate in two places
needlessly. But it's perfectly fine semantically.
> I am talking about basic facts that you could learn in the first year
> if you were taken any course in concurrent programming.
Then why does not a single person, perhaps on the entire surface of
the planet, agree with you? Why do the people who designed these
things say "yes, we designed them for event signaling"?
> It means that whenever a condition variable wait operation returns for
> you, you can have no idea whether a signal happened or a spurious
> wakeup. Hence the event is communicated via the shared variables and
> not by the condition variable (which were originally called queueing
> variable). You need the mutex to safely check the state of the shared
> variables in a busy loop and the conditon variable alias queueing
> variable is just an optimisation tool. It allows you to check the
> state of the shared variables less frequently. That is why any correct
> algorithm must work if you substitute the condition variable wait
> operation with a mutex unlock-lock pair.
This is like arguing that my bills are not communicated by the postal
service because I have to open the envelope, and the envelope may or
may not contain any given bill. You confuse *knowing* that an event
has been signaled with the signaling itself.
Yes, once you return from pthread_cond_wait, you do not know that the
event has been signaled. But it might have been, and if it was, it was
pthread_cond_wait that unblocked you because of the event.
> You and your masters seem to be not aware of that.
You seem to confuse knowing why you were signaled with having been
signaled.
> > lol; you don't need to build a semaphore out of a condvar.
> Whether you like it or not, if you try to implement the construction
> for an event signalling, you will end up with the functionality of the
> semaphore. Try it my young friend and you will see.
This is simply not true. The wakeup semantics of condition variables
make possible things that a semaphore cannot directly do. It is
certainly true that with enough work, anything you can do with one you
can do with the other, but some things are much easier with condvars
than they are with semaphores.
Try making a truly usable implementation of condition variables using
only semaphores sometime. It's quite a bit harder than you might
think. (As demonstrated by the massive number of broken condvar
implementations for Windows floating around out there.)
DS
Chris M. Thomasson
> On Aug 28, 2:45 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
>
> > > 2. Your should align the usage of mutexes, condition variables, and
> > > the protected resources.
> >
> > You mean align the internal data-structures which make up dais
> > condvars/mutexs?
> No, I do not mean nonsense.
Ummm, well, have you actually built any synchronization primitives from
scratch? Properly padding and aligning the internal data-structures which
make up said primitives is very important indeed. Its not `non-sense' in any
sense of the term...
[...]
Chris M. Thomasson
A condvar is designed for robust event signaling based on the mutations of
predicates protected by the mutex. Anytime you make a mutation to a
predicate which warrants a signal, well, that is an event in and of it self.
You signal/broadcast the condvar to deliver said event.
> > Its nice to see that you finally
> > realized that your initial conclusions were all wrong.
>
> You can use a combination of mutex and condition variable where you
> implement a construction that in effect is a semaphore. Then you can
> use it for event signalling.
You don't seem to realize that a predicate can be much more complex than a
simple counter.
> > BTW, did you know when I write the word condvar, it automatically
> > implies
> > that a mutex must be used as well?
>
> It shoud be so but it is not evident for newcommers like you and your
> beloved masters.
:^|
> > Sometimes I think you don't understand
> > that fact.
>
> You may think so but you are in error as usual. You simply
> misunderstand things due to lack of education in concurrent
> programming. When I use the terminology, self trained guys like you
> and your buddy misunderstand it.
:^|
> > You seem to think of condvar and mutex as separate, when the
> > condvar interface directly ties them together. Anytime somebody says
> > condvar, the use of a mutex is virtually a given. You make a fool out of
> > yourself when you say that a condvar cannot be used for event signaling.
> > Period.
>
> Try to use it for event signalling. Your big talk master failed to do
> his homework anyway. Period.
There you go again. Condvars can be used for event-signaling. You admitted
that you can construct semaphores out of them. Wow.
> > > The matter of
> > > fact is that it can be used, however, it must pass the condition
> > > variable test:
> > >http://groups.google.com/group/comp.programming.threads/browse_frm/th...
> > > On the other hand, for event signaling the semaphore is more simple
> > > and more safe to use.
> >
> > More simple and safe?
>
> That is it. You slowly learn something.
>
> > You don't know what the heck your talking about.
>
> I am talking about basic facts that you could learn in the first year
> if you were taken any course in concurrent programming.
>
> > To
> > prove this, well, please show me how to efficiently broadcast events
> > using a
> > semaphore and honor the proper wakeup semantics what a condvar has, and
> > how
> > waiting on a semaphore in the presence of signals is easier than using a
> > condvar?
>
> semaphore s;
> ...
> s.V();
WTF is that? I asked you to 1 show how to wait on semaphores is the presence
of async-signals. I also asked you to show how to properly broadcast to a
semaphore. And your answer was `s.V();'. What a genius! Anyway, please show
a proper implementation of `s.V()' using a POSIX semaphore? I am curious to
see how many race-conditions you can create.
> > Did you know that a condvar has certain wakeup properties that a
> > semaphore
> > simply does not have?
>
> Yes. Spurious wakeup. That is why you and your master will fail if you
> are trying to demonstrate how you use the condition variable for event
> signalling.
You totally miss the point!
> It means that whenever a condition variable wait operation returns for
> you, you can have no idea whether a signal happened or a spurious
> wakeup. Hence the event is communicated via the shared variables and
> not by the condition variable (which were originally called queueing
> variable). You need the mutex to safely check the state of the shared
> variables in a busy loop and the conditon variable alias queueing
> variable is just an optimisation tool. It allows you to check the
> state of the shared variables less frequently. That is why any correct
> algorithm must work if you substitute the condition variable wait
> operation with a mutex unlock-lock pair.
>
> You and your masters seem to be not aware of that.
Ouch. You really don't get the point I was trying to make about proper
wakeup semantics... Please read all:
http://groups.google.com/group/comp.programming.threads/msg/23266123f694774a
> > > Besides, you can use mutex and condition variable for event signaling
> > > iff you build a semaphore out of them.
> >
> > lol; you don't need to build a semaphore out of a condvar.
> Whether you like it or not, if you try to implement the construction
> for an event signalling, you will end up with the functionality of the
> semaphore. Try it my young friend and you will see.
You totally miss the point.!
> > You can use
> > events within the data-structure itself as a PREDICATE; this is beginner
> > stuff that you don't seem to be able to understand:
> This is a beginner misconception which is not surprising in your side.
> It is not any predicate but shared variables. What you call predicate
> is an expression with shared variables in it.
The predicate is the state of the queue in the link you snipped:
http://groups.google.com/group/comp.programming.threads/msg/59aa60b5ab4c2ea2
Using a semaphore in this case is 100% completely redundant because the
queue itself provides all the information the algorithm needs in order to
construct proper events such as, for instance, queue empty or full. Using a
semaphore here would be redundant because its counter is completely
superfluous.
> > .... Then buy David Butenhofs
> > excellent book and read it a couple of times.
> First he must do his homework. He had a big face talking about
> something he cannot do. At least so far he failed to do. And it is not
> an accident.
> > I know that you called him a
> > fool
> I never called him a fool. You did that several times.
Oh. I think he called you foolish.
> > and a clown;
> He is one of them since he made himself one.
lol.
> > buy his book anyway.
> I do not spend my money on outdated stuff. Especially if the author
> made a clown of himself.
wow.
> > You don't know what your missing!
> I know his errors and that I am never missing.
:^|
> > > But why should anyone building
> > > it if it is available? Simply use the right programming tool for each
> > > problem. That is it, my young friend.
> >
> > You don't know how to use complex predicates. That's your problem, not
> > the
> > condvars...
> Predicates are complex for you apparently.
Apparently, your idea of a predicate is a single counter. I understand that
they can be much more rich than that. Learn about it.
> Period.
> Calm down young friend.
:^|
Dave Butenhof
> This is a beginner misconception which is not surprising in your side.
> It is not any predicate but shared variables. What you call predicate
> is an expression with shared variables in it.
>
>> .... Then buy David Butenhofs
>> excellent book and read it a couple of times.
>
> First he must do his homework. He had a big face talking about
> something he cannot do. At least so far he failed to do. And it is not
> an accident.
You completely neglect the fact that you have no authority to assign
"homework" to anyone on this list, nor any right or excuse to pretend to
pass some sort of judgment when they refuse. Why would I possibly wish
to waste my valuable time trying to prove something to you that everyone
else already knows and that you will never admit anyway?
You have made it abundantly clear that your only purpose in
participating in this list is to annoy and insult people who are trying
to volunteer their time helping others. Your consistent use of
intentionally and pointlessly abrasive words like "master," "beginner,"
and "misconception", your entire attitude and style of writing leave
absolutely no room to doubt that you are a deliberate troll and nothing
else.
The only reason that I, or anyone on this list with any actual knowledge
to share, bothers to respond to you at all is the fear that someone who
really IS a "beginner" might listen to your nonsense. Yes, it's true
that it's unrealistic for anyone to think they can make the net safe
from trolls, but it's emotionally difficult to sit back and watch the
path of destruction you leave behind without trying to do something.
Szabolcs Ferenczi
First of all why do you feel that you have to jump on every post of
mine like a monkey? The post you just react on was not for you. Do you
feel the need to protect the over-ambitious forum-junior? Why can you
not refrain yourself, buddy?
> On Aug 28, 1:19 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
> wrote:
>
> > That is right, a condition variable is not designed for that. It is
> > only designed to optimise a busy waiting loop in terms of processor
> > cycles.
>
> You are quite possibly the only person who believes this, and the
> claim is absurd on its face.
Well, everybody having just some basic education in concurrent
programming is aware of that fact. I highly recommend you that instead
of showing arrogance here and playing the role of some monkey, you
should learn some basic stuff.
> [...]
> > You can use a combination of mutex and condition variable where you
> > implement a construction that in effect is a semaphore. Then you can
> > use it for event signalling.
>
> In other words, you can use a condition variable for signaling.
Not at all.
Well, words usually have multiple meanings and folks like you just
enjoy to confuse them. I was using the term event signalling as it is
used in concurrent programming for the problem level events. You just
intermix the problem level event with some implementation level one,
i.e. when one process notifies the other about that something has
happened with the shared variables and the other should re-evaluate
the status of them. So you just miss the point buddy, but it is just
natural from your kind.
> Guess
> what? This is precisely the kind of thing condition variables were
> invented for.
You simply do not know what the condition variables have been invented
for. You have just proven it for us. Do not think it is a POSIX
invention. There was life in concurrent programming long before POSIX
and the condition variable has been already invented. Only narrow
minded ones like you could think that they got the condition variables
with POSIX.
> [...]
> > I am talking about basic facts that you could learn in the first year
> > if you were taken any course in concurrent programming.
>
> Then why does not a single person, perhaps on the entire surface of
> the planet, agree with you?
Oh there are just many who perfectly agrees, namely anyone who has
education in concurrent programming and can use his own brain for
thinking.
> Why do the people who designed these
> things say "yes, we designed them for event signaling"?
Just tell me who do you think "designed" the condition variables.
(If you mean D. Butenhof has "designed" the condition variable or he
has come up with the concept, you are just wrong. He just taken it
over from others although he apparently did not know what he is
getting. Just ask him. He can confirm it for you. So he is not
authentic at all. He might say "yes, we designed them for event
signaling" but he has only something to do with the POSIX version of
it and that is taken over from elsewhere. It is not a POSIX invention
at all. On top of all that, he has not got a clue about where they
have "taken it" as he has proven it here already.)
> [...]
> > > lol; you don't need to build a semaphore out of a condvar.
> > Whether you like it or not, if you try to implement the construction
> > for an event signalling, you will end up with the functionality of the
> > semaphore. Try it my young friend and you will see.
>
> This is simply not true.
If not true, try it. It is your homework to show here the
corresponding code fragment. Please do not escape like the forum clown
and please refrain from telling me any more bullshit until you do your
homework. Thanks.
> The wakeup semantics of condition variables
> make possible things that a semaphore cannot directly do.
Semaphores and condition variables are there for different purpose.
You cannot use the condition variable in its own since it is just an
optimisation means to something else. In other words, the condition
variable is just an attribute which cannot be there without a
substance. Well, you cannot follow this line of thought since it is
some higher level thing and you should understand some basic
philosophy concepts as well. Forget about it, buddy. Go hacking.
> [...]
> Try making a truly usable implementation of condition variables using
> only semaphores sometime.
I will not even try it for multiple reasons. One is that I know that
others have done that already. The other reason is that condition
variables are already there. If it is there, I use it. I use the
appropriate tool for any specific problem and not try to fall into the
beginners mistake that if they learnt about something anew and they
like it, they want to over use it even if it is not applicable.
Best Regards,
Szabolcs
Szabolcs Ferenczi
> Szabolcs Ferenczi wrote:
> > This is a beginner misconception which is not surprising in your side.
> > It is not any predicate but shared variables. What you call predicate
> > is an expression with shared variables in it.
>
> >> .... Then buy David Butenhofs
> >> excellent book and read it a couple of times.
>
> > First he must do his homework. He had a big face talking about
> > something he cannot do. At least so far he failed to do. And it is not
> > an accident.
>
> You completely neglect the fact that you have no authority to assign
> "homework" to anyone on this list, nor any right or excuse to pretend to
> pass some sort of judgment when they refuse.
It is not about authority. You claimed something and if you are a man
you do prove it. Remember, you failed to prove your statement so far.
So simple is it.
You can try to escape by screaming like this but it does not really
save you.
Just to remember what we are talking about:
<quote from=
http://groups.google.com/group/comp.programming.threads/msg/7a0e9c383420d3fc
>
On Feb 21, 2:09 pm, Dave Butenhof <david.buten...@hp.com> wrote:
> Szabolcs Ferenczi wrote:
> > [...]
> > That is why you have to use semaphore for event signaling.
> That's silly.
Really? Good that we have some clever guys around. Then, I invite you
to publish your clever version here. I did publish here something that
you claim to be silly. Not very nice but we are certainly different.
Especially, I am curious to see your algorithm where you demonstrate
how do you use the condition variable for event signaling.
</quote>
> Why would I possibly wish
> to waste my valuable time trying to prove something to you that everyone
> else already knows and that you will never admit anyway?
You do not have to. It is up to you. However, until you do not do your
homework, you are proven that you do not understand the role of the
condition variable. That is the fact so far whether you like it or
not.
Remember, you said you can signal problem level event just with one
condition variable. Do it.
> You have made it abundantly clear that your only purpose in
> participating in this list is to annoy and insult people who are trying
> to volunteer their time helping others.
If you mean yourself I could only see arrogance from you on this list
before but no help. You think too much about yourself and the hybris
just overwhelms your mind. I have put here fixes for problems before
but you and the other folks just came barking around like dogs.
Helping others? What are you talking about, my friend? Just take the
discussion topic where you entered with the silly-claim.
"Do I ever need to do a sched_yield() for pthread_cond_signal(..) to
work?"
http://groups.google.com/group/comp.programming.threads/msg/fc06ff81b98a9823
There the author of the topic opener post had the same problem as this
one. He tried to use a condition variable the way as if it was a
semaphore. I have explained the problem to him and I have provided him
a fix both with semaphore and with condition variable.
The condition variable version:
http://groups.google.com/group/comp.programming.threads/msg/41fa64966fe090ca
The semaphore version:
http://groups.google.com/group/comp.programming.threads/msg/64cfa20ab92bcd12
And what did you do, my friend? You kept barking, attacking, and
showing extreme hybris and arrogance. You made claims that are
obviously wrong and what you have failed to prove them so far.
This is the fact about voluntarily helping the others, my friend.
> [...]
> The only reason that I, or anyone on this list with any actual knowledge
> to share, bothers to respond to you at all is the fear that someone who
> really IS a "beginner" might listen to your nonsense.
Well, if you say that the condition variable test is a nonsense,.
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/0ff7ac10adadee22
you are proving your own incompetence. However, it is not because I
say so.
If you were smart enough to see the value of the simple stuff like
that you could help others to start using it and they could avoid easy
mistakes like the starter of this discussion thread. However, it is so
simple test and it can help so much to the inexperienced ones. That
much about voluntarily helping the others, buddy.
You might think about yourself that you are a God or something similar
super creature but really you cannot understand a basic thing due to
your enormous hybris.
> Yes, it's true
> that it's unrealistic for anyone to think they can make the net safe
> from trolls,
The biggest troller here is your little pet whom you were trying to
defend by entering with the silly-note into the discussion where he
proved incompetence. You just blindly joined to him by your ignorance
and arrogance.
Talking about trolling, it is just enough to remember you on the buddy
who just blindly jumps at any of my posts just like a crazy monkey.
A simple example: Just see what humble helping advice I have added to
the topic starter here in this discussion thread and what you and your
troller friends have made out of it. It is amazing. And it happens
from time to time. On top of all that, you and the like call me a
troller. Incredible aggression what can only come from your countrymen
in the whole world.
> but it's emotionally difficult to sit back and watch the
> path of destruction you leave behind without trying to do something.
Instead of sitting back, try to do your homework, I would advise to
you.
Best Regards,
Szabolcs
Alexander Terekhov
Szabolcs Ferenczi wrote:
[...]
> Semaphores and condition variables are there for different purpose.
True.
http://www.opengroup.org/onlinepubs/007904975/xrat/xsh_chap02.html#tag_03_02_09
"....
A semaphore is defined as an object that has an integral value
and a set of blocked processes associated with it. If the value
is positive or zero, then the set of blocked processes is empty;
otherwise, the size of the set is equal to the absolute value
of the semaphore value. The value of the semaphore can be
incremented or decremented by any process with access to the
semaphore and must be done as an indivisible operation. When
a semaphore value is less than or equal to zero, any process
that attempts to lock it again will block or be informed that
it is not possible to perform the operation.
A semaphore may be used to guard access to any resource
accessible by more than one schedulable task in the system.
It is a global entity and not associated with any particular
process. As such, a method of obtaining access to the semaphore
has to be provided by the operating system. A process that wants
access to a critical resource (section) has to wait on the
semaphore that guards that resource. When the semaphore is
locked on behalf of a process, it knows that it can utilize
the resource without interference by any other cooperating
process in the system. When the process finishes its operation
on the resource, leaving it in a well-defined state, it posts
the semaphore, indicating that some other process may now
obtain the resource associated with that semaphore.
In this section, mutexes and condition variables are specified
as the synchronization mechanisms between threads.
These primitives are typically used for synchronizing threads
that share memory in a single process. However, this section
provides an option allowing the use of these synchronization
interfaces and objects between processes that share memory,
regardless of the method for sharing memory.
Much experience with semaphores shows that there are two
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
distinct uses of synchronization: locking, which is typically
of short duration; and waiting, which is typically of long or
unbounded duration. These distinct usages map directly onto
mutexes and condition variables, respectively.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Semaphores are provided in IEEE Std 1003.1-2001 primarily to
provide a means of synchronization for processes; these processes
may or may not share memory. Mutexes and condition variables are
specified as synchronization mechanisms between threads; these
threads always share (some) memory. Both are synchronization
paradigms that have been in widespread use for a number of years.
Each set of primitives is particularly well matched to certain
problems.
With respect to binary semaphores, experience has shown that
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
condition variables and mutexes are easier to use for many
synchronization problems than binary semaphores. The primary
reason for this is the explicit appearance of a Boolean
predicate that specifies when the condition wait is satisfied.
This Boolean predicate terminates a loop, including the call
to pthread_cond_wait(). As a result, extra wakeups are benign
since the predicate governs whether the thread will actually
proceed past the condition wait. With stateful primitives,
such as binary semaphores, the wakeup in itself typically
means that the wait is satisfied. The burden of ensuring
correctness for such waits is thus placed on all signalers
of the semaphore rather than on an explicitly coded Boolean
predicate located at the condition wait. Experience has
shown that the latter creates a major improvement in safety
and ease-of-use.
Counting semaphores are well matched to dealing with
producer/consumer problems, including those that might exist
between threads of different processes, or between a signal
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
handler and a thread. In the former case, there may be little
or no memory shared by the processes; in the latter case,
one is not communicating between co-equal threads, but
between a thread and an interrupt-like entity. It is for
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
these reasons that IEEE Std 1003.1-2001 allows semaphores
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
to be used by threads.
^^^^^^^^^^^^^^^^^^^^^
Mutexes and condition variables have been effectively used
with and without priority inheritance, priority ceiling,
and other attributes to synchronize threads that share
memory. The efficiency of their implementation is comparable
to or better than that of other synchronization primitives
that are sometimes harder to use (for example, binary semaphores).
Furthermore, there is at least one known implementation of Ada
tasking that uses these primitives. Mutexes and condition
^^^^^^^^^^^^^^^^^^^^^
variables together constitute an appropriate, sufficient,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
and complete set of inter-thread synchronization primitives."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
regards,
alexander.
Szabolcs Ferenczi
> Szabolcs Ferenczi wrote:
>
> [...]
>
> > Semaphores and condition variables are there for different purpose.
>
> True.
Thanks.
BWT you are very good at copy-paste.
Best Regards,
Szabolcs
Alexander Terekhov
Thanks.
Did you read it (copy-paste)? Here's one more chance for you, stupid:
Szabolcs Ferenczi
> Szabolcs Ferenczi wrote:
>
> > On Aug 30, 6:10 pm, Alexander Terekhov <terek...@web.de> wrote:
> > > Szabolcs Ferenczi wrote:
>
> > > [...]
>
> > > > Semaphores and condition variables are there for different purpose.
>
> > > True.
>
> > Thanks.
> > BWT you are very good at copy-paste.
>
> Thanks.
> Did you read it (copy-paste)? Here's one more chance for you, stupid:
>
Very well. You are the master of copy-paste. If you have something to
say, go ahead, my friend. Do not be so shy.
Otherwise, if you do not have any own ideas, please refrain to tell
stupid.
Best Regards,
Szabolcs
Alexander Terekhov
Szabolcs Ferenczi wrote:
[...]
> If you have something to say, go ahead, my friend. Do not be so shy.
A semaphore is defined as an object that has an integral value
More:
http://www.opengroup.org/onlinepubs/007904975/xrat/xsh_chap02.html#tag_03_02_09
regards,
alexander.
Szabolcs Ferenczi
> Szabolcs Ferenczi wrote:
>
> [...]
>
> > If you have something to say, go ahead, my friend. Do not be so shy.
>
> A semaphore is defined as an object that has an integral value
> and a set of blocked processes associated with it. If the value
My dearest copy-paste master,
if you just omit the quotation mark and copy-paste the text from
other sources pretending that these are you own words, it is
plagiarism. I thought you were more intelligent than that. However,
anyone can be mistaken.
Thanks for your effort anyway, but just copying large portion of text
three times in a row like a monkey is not necessary.
Best Regards,
Szabolcs
Alexander Terekhov
Szabolcs Ferenczi wrote:
[...]
> Thanks for your effort anyway, but just copying large portion of text
> three times in a row like a monkey is not necessary.
So why do you keep posting nonsense about semaphores v. condvars? Will
you stop now?
Szabolcs Ferenczi
> Can anyone give me some tips on what I might be doing wrong?
I had three remarks to you in my earlier post
http://groups.google.com/group/comp.programming.threads/msg/4332cf295ec76cc8
After so much hassle I can imagine that you might not see exactly what
I proposed to you. So, to be exact, I am going to demonstrate points 2
and 3:
<quote>
2. Your should align the usage of mutexes, condition variables, and
the protected resources.
3. You should consider using simple semaphores for event signaling
(which is your problem to solve) instead of the more complicated
mutex---condition variable pairs which are not designed for this
task.
</quote>
To start with, I copy the relevant lines from you post here since I am
going to focus on one subproblem only:
pthread_cond_t forward_h_cond_worker, forward_h_cond_manager;
...
void *forward_h_worker(void *in)
{
pthread_mutex_lock(&forward_h_lock[group]);
...
pthread_cond_wait(&forward_h_cond_worker,
&forward_h_lock[group]);
...
}
void forward_h_manager(float *inputs, float *outputs, h_weights_t
*h_weights)
{
...
pthread_cond_broadcast(&forward_h_cond_worker);
//for (i=0; i<4; i++) {
// pthread_cond_signal(&forward_h_cond_worker);
//}
...
}
Now it is obvious for anyone having just a basic training in
concurrent programming that you are trying to communicate a problem
level event from the manager thread toward the worker threads. The
problem level event is that workers can start working now.
The basic problem here is that you use a condition variable just the
way if you used a semaphore. However, your algorithm works if you
simply replace the condition variable 'forward_h_cond_worker' with
semaphores (see point 3 above):
sem_t forward_h_cond_worker[4]; /* initialise it to closed */
...
void *forward_h_worker(void *in)
{
...
sem_wait(&forward_h_cond_worker[group]);
...
}
void forward_h_manager(float *inputs, float *outputs, h_weights_t
*h_weights)
{
...
for (i=0; i<4; i++) {
sem_post(&forward_h_cond_worker[i]);
}
...
}
Here, the problem level event is represented by semaphore variables.
Fine.
Of course you can fix the algorithm in another, a more complicated way
too. But then, you have to introduce shared flag variables next to the
condition variable for representing the problem level event. Note that
that variable is missing from the original post (see point 2 above).
Nevertheless, here is the fixed version with the condition variable
too:
pthread_mutex_t forward_h_lock = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t forward_h_cond_worker = PTHREAD_COND_INITIALIZER;
volatile int forward_go[4];
...
void *forward_h_worker(void *in)
{
...
pthread_mutex_lock(&forward_h_lock);
while (0 == forward_go[group])
pthread_cond_wait(&forward_h_cond_worker[group],
&forward_h_lock);
forward_go[group] = 0;
pthread_mutex_unlock(&forward_h_lock);
...
}
void forward_h_manager(float *inputs, float *outputs, h_weights_t
*h_weights)
{
...
pthread_mutex_lock(&forward_h_lock);
for (i=0; i<4; i++) {
forward_go[i] = 1;
}
pthread_cond_broadcast(&forward_h_cond_worker);
pthread_mutex_unlock(&forward_h_lock);
...
}
Can you recognise the semaphore functionality? However, we needed a
flag variable, a mutex, and a condition variable whereas a single
semaphore would do. In this respect, for the problem level event
signalling the semaphore is an all-in-one device. Furthermore the
condition variable version needs nine lines of code more. It is not
about typing but it is about possible errors. The more lines of code
the more chance for errors.
By the way, which version seems simpler to you for this task, i.e that
the manager thread SIGNALS AN EVENT to the worker thread? The event
being "you can start working." The one with the semaphore or the one
with the condition variable?
In this latter version, the problem level event is projected on the
variable 'forward_go[4].' The event these folks like to talk about is
an implementation level event, which is projected on the condition
variable. Note, however, that this event does not belong to the
business logic of the program, it is just an implementation
requirement if and only if you want to optimise your algorithm. And
normally you do want it. So, a version without any condition variable
represents exactly the same busyness logic of the program (see also
"The condition variable test"):
pthread_mutex_t forward_h_lock = PTHREAD_MUTEX_INITIALIZER;
volatile int forward_go[4];
...
void *forward_h_worker(void *in)
{
...
pthread_mutex_lock(&forward_h_lock);
while (0 == forward_go[group]) {
pthread_mutex_unlock(&forward_h_lock);
pthread_mutex_lock(&forward_h_lock);
}
forward_go[group] = 0;
pthread_mutex_unlock(&forward_h_lock);
...
}
void forward_h_manager(float *inputs, float *outputs, h_weights_t
*h_weights)
{
...
pthread_mutex_lock(&forward_h_lock);
for (i=0; i<4; i++) {
forward_go[i] = 1;
}
pthread_mutex_unlock(&forward_h_lock);
...
}
So this latter exercise only shows that the condition variable does
not belong to the business logic of the solution to the problem rather
it is an optimisation at the implementation level.
There might be misspellings or minor issues in the solutions I have
shown but I hope you can get the idea now. Do not worry, if I have
made the slightest mistake, forum fighters will come.
Best Regards,
Szabolcs
Alexander Terekhov
Szabolcs Ferenczi wrote:
[...]
> There might be misspellings or minor issues in the solutions I have
> shown but I hope you can get the idea now. Do not worry, if I have
> made the slightest mistake, forum fighters will come.
He!He! Ha!Ha! Ho!Ho!
http://www.opengroup.org/onlinepubs/007904975/xrat/xsh_chap02.html#tag_03_02_09
"....
A semaphore is defined as an object that has an integral value
and a set of blocked processes associated with it. If the value
regards,
alexander.
Szabolcs Ferenczi
> "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
> > > To
> > > prove this, well, please show me how to efficiently broadcast events
> > > using a
> > > semaphore and honor the proper wakeup semantics what a condvar has, and
> > > how
> > > waiting on a semaphore in the presence of signals is easier than using a
> > > condvar?
>
> > semaphore s;
> > ...
> > s.V();
>
> WTF is that?
You cannot know WTF is that since you are just a self educated hacker
in this field.
> [...] Anyway, please show
> a proper implementation of `s.V()' using a POSIX semaphore? I am curious to
> see how many race-conditions you can create.
Here you are:
sem_post(&s);
Remark: Now you can see the lack of education in concurrent
programming. You do not know anything about when, how, and for what
programming tools in concurrent programming have been invented but you
try to talk big just like your masters. If you are curious, that is
fine, then you should really consider taking a basic course in
concurrent programming! You would then learn when the semaphore was
invented (not in POSIX and not by Butenhof anyway) the basic
operations on the semaphore was named 'P' and 'V' operations. In fact
these letters are initial letters from the corresponding Dutch words
since the inventor of the semaphore was a Dutch man and not the
hybrisful POSIX guys not even the crazy copy-paste master.
Best Regards,
Szabolcs
Dave Butenhof
> Szabolcs Ferenczi wrote:
> [...]
>> Thanks for your effort anyway, but just copying large portion of text
>> three times in a row like a monkey is not necessary.
>
> So why do you keep posting nonsense about semaphores v. condvars? Will
> you stop now?
No, of course he won't. He has no interest in anything but throwing
pointless and empty insults. Whether or not he actually has any
knowledge of concurrent programming is difficult to determine through
his persistent murk of obnoxious abuse; but it's clear that he doesn't
care about anything he knows, or anything you know; he only cares about
making a name for himself by annoying everyone.
He's found a "hot button" that gets him noticed, and he'll probably only
stop when everyone stops "feeding the troll" and he no longer gets any
attention from being a public idiot.
Chris M. Thomasson
On Aug 29, 6:14 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
> > > > > To
> > > > > prove this, well, please show me how to efficiently broadcast
> > > > > events
> > > > > using a
> > > > > semaphore and honor the proper wakeup semantics what a condvar
> > > > > has, and
> > > > > how
> > > > > waiting on a semaphore in the presence of signals is easier than
> > > > > using a
> > > > > condvar?
> > >
> > > > semaphore s;
> > > > ...
> > > > s.V();
> > >
> > > WTF is that?
> You cannot know WTF is that since you are just a self educated hacker
> in this field.
:^|
> [...] Anyway, please show
> a proper implementation of `s.V()' using a POSIX semaphore? I am curious
> to
> see how many race-conditions you can create.
> Here you are:
>
> sem_post(&s);
Listen moron, I said show me how you would efficiently broadcast events
using a semaphore and honor the proper wakeup semantics that a condvar has.
> Remark: Now you can see the lack of education in concurrent
> programming. You do not know anything about when, how, and for what
> programming tools in concurrent programming have been invented but you
> try to talk big just like your masters. If you are curious, that is
> fine, then you should really consider taking a basic course in
> concurrent programming! You would then learn when the semaphore was
> invented (not in POSIX and not by Butenhof anyway) the basic
> operations on the semaphore was named 'P' and 'V' operations. In fact
> these letters are initial letters from the corresponding Dutch words
> since the inventor of the semaphore was a Dutch man and not the
> hybrisful POSIX guys not even the crazy copy-paste master.
lol.
Chris M. Thomasson
>> but it's emotionally difficult to sit back and watch the
>> path of destruction you leave behind without trying to do something.
>
> Instead of sitting back, try to do your homework, I would advise to
> you.
:^|
Dave Butenhof
> On Aug 29, 6:14 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
>> "Szabolcs Ferenczi" <szabolcs.feren...@gmail.com> wrote in message
> words since the inventor of the semaphore was a Dutch man and not the
> hybrisful POSIX guys not even the crazy copy-paste master.
Wow. Such brilliance. We're awed.
Unfortunately for you, although "V" is indeed the first letter of
verhogen, the Dutch word for "increase", Djikstra coined his own
"portmanteau" word (as much Dutch as "vorpal and brillig" are English)
for what we often term the "lock" or "wait" operation. His intent was to
represent the semantic concept "try to decrease" (probeer te verlagen),
as well as to abbreviate the operation with a distinct letter, P. (Since
it would have been endlessly confusing to discuss the complementary "V"
and "V" operations on semaphores.)
If you're going to be annoying and try to make yourself sound smart by
arguing about trivial and irrelevant details instead of real
information, at least do a quick search and get it right, OK?
Speaking of made up words, what's "hybrisful" supposed to mean, anyway?
That's not a sarcastic question, by the way; although your sentence
structure often betrays you as a non English speaker, (and likely not a
particularly outstanding writer in any language), your vocabulary is
usually fairly clear. However I really can't guess which pointless and
juvenile insult you intended in this case. You'll have to be more clear.
David Schwartz
wrote:
> Can you recognise the semaphore functionality? However, we needed a
> flag variable, a mutex, and a condition variable whereas a single
> semaphore would do. In this respect, for the problem level event
> signalling the semaphore is an all-in-one device. Furthermore the
> condition variable version needs nine lines of code more. It is not
> about typing but it is about possible errors. The more lines of code
> the more chance for errors.
PLEASE DO NOT FEED THE TROLLS.
DS