Re: Threads docs updated in CVS

From: flameframe_at_[hidden]
Date: 2001-08-13 09:22:50

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> 
> > - some lock in my code requires
> >    lock/unlock mutex + set event call
> > - in Programming with POSIX Threads
> >    lock/unlock mutex + CV management
> >
> > I am by no means a threading expert but from the above I can not 
make
> > deduction that event's price is higher.
> 
> your code does require set/reset to be done with
> mutex locked to achieve correct behavior.

Yes. Exactly.

> 
> with condition variables you do not have to
> do signal with mutex locked to achieve correct
> behavior 

Nice that I have not to do something :-). But I do not see an 
advantage in just a different program flow. 

> (actually, signalling after mutex.unlock
> should result in more efficient execution).. 

Is it just a supposal or a result of a real experience ?

> it
> has some special meaning, however. on uniprocessor
> with priority scheduling you could achieve predictable
> scheduling doing signaling with mutex locked. that is
> what "hard-realtime" applications sometime really need..
> 

As I can understand it says in favour of my code, isn't ?

> > Anyway, I have mentioned event-based solutions just to object 
that it
> > always result either to race conditions or to CV-equivalent.
> 
> well, i think it does ;) WaitForMultiple( mutex,event...)
> is a sort of inefficient monitor which should better be
> implemented as CV-based "equivalent" (another solution
> could be based on SignalAndWait "equivalent" but then you
> would have a problem with respect to win32 thread suspension,
> etc..).
> 
> regards,
> alexander.

What do you mean with 'inefficient'? I will be really glad to change 
my threading code to something more efficient but, as I have already 
asked, - do you have real time comparision results between two models 
or it is just your feeling?

Best regards,
Vitalij.