Re: Threads docs updated in CVS

From: flameframe_at_[hidden]
Date: 2001-08-14 04:33:00

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> 
> > > 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.

Let see how many synchronization calls is performed in both cases to 
obtain e.g. read lock (Win32 impl).

my example
~~ ~~~~~~~
1) WaitForSingleObject(mutex)
2) ResetEvent(noReaders)
3) ReleaseMutex(mutex)

example from book + boost cv impl.
~~~~~~~ ~~~~ ~~~~   ~~~~~ ~~ ~~~~~
1) WaitForSingleObject(mutex)

2) CV wait -> see what is this from condition.cpp
   -- enter_wait function -- 
      2.1) WaitForSingleObject(m_gate) 
      2.2) ReleaseSemaphore   (m_gate)
   2.3) ReleaseMutex(mutex)
   -- do_wait function -- 
      2.4) WaitForSingleObject(m_queue)
      2.5) WaitForSingleObject(m_mutex)
      2.6) ReleaseSemaphore(m_gate) //optional
      2.7) ReleaseMutex(m_mutex) 
      2.8) WaitForSingleObject(m_queue) // optional but inside for()! 
      2.9) ReleaseSemaphore(m_gate) //optional
   2.10) WaitForSingleObject(mutex)

3) ReleaseMutex(mutex)

Now I will ask you - are you still _sure_ that CV solution will 'do 
things "faster"' ???

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

Of course if we start to imagine strange things we can get to strange 
results. But now we are talking about a concrete example. I do not 
see how your argument apply to this case. 

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

Hmm. I was not advertising WaitForMultiple. I have just used it w/o 
any interest that it is "simply" monitor with limited capabilities. 
For RWLock it is fine enough. 

Another fact is that there is no performance comparision between 
these models yet. And speaking that CV-based solution is faster 
because CV is nice thing is useless. I would even say that boost CV 
will be slower because in this case it is just superstructure of 
Win32 primitives.

And resuming. I do not vote against CV in Boost.Thread at all.
And not talking about performance. 
In fact I was just answering a mail from Bill Kempf (15850) where 
he "can challenge you to do so and I'm willing to bet I can show race 
conditions with each of your attempts." 

Best regards,
Vitalij.