Andres Kroonmaa wrote:
> thats sure. The only thing to keep in mind is that running thread can't easily
> trigger other cpu. There must be suitable conditions for that, other cpu must
> be necessarily suspended in either halt or some mutex spin, and running cpu
> must parse through all the internals to find that out. Its slow.
As long as it gets triggered when we cond_signal I see no problem.
> > I still maintain that two cond_signal from the same thread SHOULD
> > unblock "at least two threads" however.
>
> yes, thats true. quite likely on most OSes.
And it is also true that I do not care. If it happens that two
cond_signal gets optimized down to a single signal I am equally happy
for Squid.
> Whatever the docs say, cond var should not be touched outside mutex.
> There are some rare cases when race conditions could cause a thread deadlock.
> Not the one signalling, but the one waiting on condvar.
> And this would happen, on one OS or other. I've had these on Solaris 2.5 or 2.6,
> even UP back then. Maybe these days such things are avoided, and iirc this
> can be recovered by timedwait, so in a sense, not very important, but this could
> cause other weird interactions that we'd better avoid. Win is very questionable
> and very small.
What kind of deadlock are we talking about here?
a) A lost cond_signal, causing the waiting threads to never wake up
b) A internal deadlock, making the threads subsystem hang and not
recover again even if additional cond_signal is sent.
'a' is fully expected and must be dealt with if using cond_signal
outside the mutex.
'b' would be implementation bugs.
Bug you are probably right. Normal use of cond signals always involve a
mutex, and this is most likely the code path that has been tested and
verified. If there is implementation bugs then these are likely to crop
up when doing odd things like using cond_signal outside mutex protection
etc..
Regards
Henrik
Received on Sat Jan 04 2003 - 07:57:32 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:19:05 MST