Re: Threads: New Win32 Implementation

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-07 09:15:33

--- In boost_at_[hidden], Levente Farkas <lfarkas_at_m...> wrote:
> William Kempf wrote:
> > This is in the e-groups archive, as we've discussed it from the
> > beginning.  Simply put, lock/unlock methods are dangerous to use,
> > especially with exceptions.  If an "auto lock" class will do the 
same
> > thing more safely, and with the same performance, then we're 
better
> > off not exposing the lock/unlock functions at all.
> 
> I didn't read the archive, but this is not true. it's one of the 
biggest 
> problem in java thread (and that was one of the main reason that in 
this
> year on javaone at least 3 main session about "a new concurent 
library for
> java"), the syncronyzed keyword have to be around a block, auto-
lock can't
> always do the same thing, ie. you can't do the following:
> Mutex m1, m2;
> m1.lock();
> <may be some code>
> m2.lock();
> <may be some code>
> m1.unlock();
> <may be some code>
> m2.unlock();
> in the current setup a we loose a BIG functionality!!!

Nope.  C++ isn't Java.  If we absolutely had to have overlapping 
locks like that we could place the locks on the heap.  Thus 'm1.lock
()' becomes 'plk1 = new mutex::lock(m1)' and 'm1.unlock()' 
becomes 'delete plk1'.  Ugly?  Yes, but that could be considered a 
good thing, since it puts up a red flag that what we're doing is 
unsafe.

If that's not good enough, the better solution than exposing 
lock/unlock on the mutex is to add lock/unlock functions to the lock 
objects, though I wouldn't recommend it (this reduces the safety of 
the condition::wait() since we're no longer assured that the mutex is 
properly locked).

The simple fact, to me at least, is that the example you give here is 
EXTREMELY rare, and in fact should be avoided when possible for 
numerous reasons.  How often have you really had a need to use 
overlapping locks?

> those user who would like to write safe code will always use the 
> guard/auto_lock, but if the problem/solution requires he can lock 
manualy.
> Sometimes it's a must that lock in one function and unlock in 
another.

Another very rare need indeed!  Also "solvable" by placing the lock 
on the heap (and probably using an auto_ptr to pass it around!).

> I think the above argument is that we have to suuport all stupid 
> programmes too not the best choise. I always prefere safe code over 
unsafe
> even if it's same preformance loose, but the above have too much 
loose.
> (anyway in java assamply you can do the lock and unlock but not in 
a valid
> java code).

We don't have to work around the problem here, we just have to use 
the lock in a different manner.  Portable, relatively safe and 
strongly illustrates the dangers when used.

> > As for the name... that's not as big of an issue right now.  I 
prefer
> > lock, and you could still have read_lock, write_lock, etc.  I 
prefer
> > it mostly because it's more intuitive to new users exactly what 
this
> > means.  The interface isn't locked in yet, though, so the name 
isn't
> > set in stone yet.
> 
> my naming convention come from the above statement, if the the 
lock/unlock
> function used it's easier to remember as a function and guard as an
> auto-lock.

Well, I still don't think you want to expose the function so I'm 
still in favor of lock as the name for the "auto lock".
  
> > > 2. I realy hate when see the GetTickCount() funtion. it's not an
> > ansi
> > >    function and I always prefere ansi function where it's 
possible
> > even
> > >    in platform specific code. there is a clock() and other ansi
> > function
> > >    to mesaure time.
> > > yours.
> > 
> > I considered this, but stuck with GetTickCount() because it is
> > platform specific code and GetTickCount() returns milliseconds,
> > whereas clock() would have to be used in a mathematical 
calculation
> > using CLOCKS_PER_SEC to determine milliseconds.  So GetTickCount()
> > seemed safe and much easier to deal with for this specific case.
> 
> I think eevn it's platform specific code most of these line can be 
used
> on all platform, but in this case a few less lines:-)(

A very few less.  I can change it if it's that large of an issue... 
remember this code is a proof of concept and not a submission for 
acceptance into boost.  I feel justified in how it's coded now, but 
if the code should ever progress to the point where it will be 
submitted for boost approval then I could be persuaded to modify this.

Bill Kempf