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

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-09-08 15:07:20

From: William Kempf <sirwillard_at_[hidden]>
> ....
> 
> There's not a need to convert from a try_lock to a lock.  The only 
> danger with the current interface is that a bad programmer could code 
> the following:
> 
> mutex::try_lock tlk(mx);  // Assume it fails
> cond.wait(tlk, ...);  // We aren't really locked here!
> 
> This seems like a big hole in the safety I've been discussing here.  
> However, it's a different topic.  If you fail to check a try_lock or 
> timed_lock for success you've entered undefined territory with or 
> with out the call to wait().  This is why I originally thought that 
> these types of locks should throw an exception if they failed to 
> construct (failed to lock), but the consensus was that this was 
> overkill.  For right now I'm going to not take sides on this and will 
> leave it with a need to check validity after construction.

I agree that throwing an exception is a much safer interface, and
reasonably clean to use.  I don't see that this

   try {
      mutex::try_lock tlk(mx);
      cond.wait(tlk, ...);
      DoSomethingInteresting();
   } catch (failed_try) {
      DoSomethingElse();
   }

is any harder to write than this

   mutex::try_lock tlk(mx);
   if (tlk)
   {
     cond.wait(tlk, ...);
     DoSomethingInteresting();
   } else {
     DoSomethingElse();
   }

In many cases I find it even more convenient for timeouts to
throw an exception, as it is not usually something that I can
handle at the point where it occurs.

And as an aside, here is another interesting discussion of
what is broken about the Java thread model:

   http://www.cs.umd.edu/~pugh/java/memoryModel/jsr.html

My favorite quote:

   Chapter 17 of the Java Language Specification (and Chapter 8
   of the Java Virtual Machine Specification) describe the
   semantics of threads and locks, as well as related features
   such as volatile variables. Unfortunately, that specification
   has been found to be very hard to understand and has many
   subtle, unintended implications. It is unclear if anyone
   actually understands the entire specification and its
   implications. 

I am glad to see us working so hard to do a better job, however
frustrating the discussion can sometimes get.