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

From: Bill Wade (bill.wade_at_[hidden])
Date: 2000-09-07 09:53:20

> From: Levente Farkas [mailto:lfarkas_at_[hidden]]

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

Java synchronized looses the functionality, but an AutoMutex may be more
flexible.

For instance, auto_ptr can take ownership at times other than creation
(reset()) and release() ownership at times other than destruction.  The safe
guarantee it makes is that if it has ownership when destroyed, it deletes
the object.

Mutex m1,m2;

{
  AutoMutex a1(m1);	// Implicit call to m1.lock()
  AutoMutex a2(m2, DO_NOT_LOCK_NOW);
  < code1 >
  a2.lock();
  < code 2 >
  a1.unlock();
  < code 3 >
  // Implicit call to m2.unlock()
}

The difference is that if an exception (or other early exit from the block)
occurs any current locks are released.  Note that it may take a good
optimizing compiler (and inlined AutoMutex members) to get exactly the same
performance from AutoMutex, but at worst the cost is small (the AutoMutex
might need to hold a pointer to the Mutex and a counter or bool showing the
current lock status).