[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: DESIGN-condvar

phil-list redhat com schrieb am 11.10.02 10:23:12:
> On Wed, 9 Oct 2002, Alexander Terekhov wrote:
> > Q2) POSIX does require that deleting a condition variable 
> >     after final signaling should be OK/safe(*). Are you 
> >     sure that this would actually work under the current 
> >     DESIGN-condvar?
> i think you are right, cond_signal() + free() is unsafe.
> does broadcast require the same semantics, ...

I think that both signal() and broadcast() [actually the 
main problem is in *wait(), AFAICS] functions require the 
same semantics with respect to ``It shall be safe to 
destroy an initialized condition variable upon which no 
threads are currently blocked.'' Unless I'm just missing

phil-list redhat com schrieb am 11.10.02 10:09:08:
> On Wed, 9 Oct 2002, Alexander Terekhov wrote:
> > Q1) Are you sure that given the current CV design, it's 
> >     really guranteed that a player just can't consume his 
> >     own signal as spurious wakeup... resulting in a sort 
> >     of deadlock (until the main/initial thread would come
> >     it and resolve it declaring game over)?
> do you mean: "a cond_wait()-ing thread should not be woken up by a
> cond_signal() it did previously" ?
> ( Please describe your question(s) in simpler terms, not through some
> complex example. Providing the simplest possible description for a problem
> is just as important as implementing the simplest possible code for a
> given specification. Too complex examples only cause us to 1) not be able
> to read your description immediately or 2) even to skip it altogether.  
> Having simple examples and even suggestions for fixes will save tons of
> time on our side, and tons of typing on your side. Thanks! )

Well, I'm sorry, but the best that I can do at the moment
is to point you to the following {rather old} c.p.t. thread:

(Subject: Re: pthread_cond_* implementation questions)

and the following {semaphore-based} CV implementation:

(see pthread_cond_wait.c and pthread_cond_signal.c)

The only problem is that due to lack of *explicit* queuing,
pure semaphore-only-based impl, unfortunately, does require 
somewhat silly locking across thread context switching. :-(


Die clevere Geldreserve: der DiBa-Privatkredit. Funktioniert wie ein Dispo, 
ist aber viel gunstiger! Alle Infos: http://diba.web.de/?mc=021104

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]