On Thu, 6 Dec 2007, Tim Prins wrote:
Tim Prins wrote:
First, in opal_condition_wait (condition.h:97) we do not release the
passed mutex if opal_using_threads() is not set. Is there a reason for
this? I ask since this violates the way condition variables are supposed
to work, and it seems like there are situations where this could cause
deadlock.
So in (partial) answer to my own email, this is because throughout the
code we do:
OPAL_THREAD_LOCK(m)
opal_condition_wait(cond, m);
OPAL_THREAD_UNLOCK(m)
So this relies on opal_condition_wait not touching the lock. This
explains it, but it still seems very wrong.
Yes, this is correct. The assumption is that you are using the
conditional macro lock/unlock with the condition variables. I personally
don't like this (I think we should have had macro conditional condition
variables), but that obviously isn't how it works today.
The problem with always holding the lock when you enter the condition
variable is that even when threading is disabled, calling a lock is at
least as expensive as an add, possibly including a cache miss. So from a
performance standpoint, this would be a no-go.
Also, when we are using threads, there is a case where we do not
decrement the signaled count, in condition.h:84. Gleb put this in in
r9451, however the change does not make sense to me. I think that the
signal count should always be decremented.
Can anyone shine any light on these issues?
Unfortunately, I can't add much on this front.
Brian
