Re: Threads docs updated in CVS

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-08-13 11:26:12

> > 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.

the advantage is that you have less amount of synchronized
code - you program threads spend less time waiting for
access (mutex ownership) and could do things "faster"/
with more concurrency - you could see the improvements
"immediately" if you run your program on a system with
more that one processor available to your threads.

> > (actually, signalling after mutex.unlock
> > should result in more efficient execution)..
>
> Is it just a supposal or a result of a real experience ?

imagine that you have another reader (or writer) already
spinning on you mutex and waiting for access (or if you
do not like MP/spinlocks impl. details, imagine that he
is just calling mutex.lock in parallel).. you better give
him access sooner than later so that he could do his work
faster without any delays (he does not need to wait
until you have finished your potentially NOOP signaling
operations and/or he might already become done with his
work by the time the thread(s) which you unblock via
non-NOOP signal(s) get a chance to run somewhere).

> > 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 ?

well, if you program some hard-realtime application for
some uniprocessor hardware then yes.

> > > 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?

i do not have real time comparisons (note that windows does not
support CVs natively). it is just my feeling with respect to how
waitformultiple impl could look like and some experience with my
own implementation of waitformultiple for posix threads (to simplify
porting of some old win32 code to linux). waitformultiple is a
"simple" monitor with rather limited capabilities - any or all;
which does even tell you "how many; which ones" in the case of
"any" with more than one object in signaled state.

regards,
alexander.

ps. if you want have some fun read the following "WaitForMultiple"
article and the source code

http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0197/win32/win320197.htm&nav=/msj/0197/newnav.htm

from MS systems jornal..

"A You are correct: Win32 does not offer an API that allows
you to wait on multiple Boolean expressions. But with a little
creative use of the existing Win32 APIs, you can create your
own WaitForMultipleExpressions function that does what you want.
I created my own WaitForMultipleExpressions function that works
on Windows® 95 and Windows NT® 4.0 or later."

please note that it does not work with mutexes..