Re: [boost] Re: Threads: New Win32 Implementation

From: Levente Farkas (lfarkas_at_[hidden])
Date: 2000-09-07 08:49:23

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

 -- Levente
 "The only thing worse than not knowing the truth is
  ruining the bliss of ignorance."