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

From: Levente Farkas (lfarkas_at_[hidden])
Date: 2000-09-07 09:43:22

William Kempf wrote:
> 
> --- 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

that's the main point. we have to be better performance, with wider
features.

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

this isn't likes to me. if we alread have a change to lock and unlock
explicitly why we make it so difficult. those who read the manual and
know what is the guard for probably always will use it (if possible),
and those who don't know what they are doing will be in trauble anyway.
 
> 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).

condition can be a friend (as it's now AFAI remember) so condition can
check the mutex state.
 
> 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?

eg in may last project, the above was a read example. yes of course if
we've got privmitives which are equivalent with another set than we can
do the same think over both set, but one of them can be very difficult.
so I sure I can reorganize my code to use just "java style" blocked guard,
but I have to use more mutex and/or condition and the code wouldn't be
so easy to read.
 
> > 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!).

everything is solvable, but the price ...
anyway in an oop word, it obious to me if I've an object which can be
lock nad unlock than it have two function a lock nad an unlock.
why the stream classes wasn't designed to be a helper class to open
and close it ?
 
> 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.

I think it has nothing to do with portable. and the mt stuff is always
dangerous nad hard to debug and ...
 
> > 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".

I hope I expose now a bit more:-)
 
> > 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.

I think it's just a minor issue and I don't realy care about it (since it's
platform specific code), it just catch my eyes, since I always have to say 
it to our developers when I start to port something to linux from win32.

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