Re: New file uploaded to boost

From: williamkempf_at_[hidden]
Date: 2001-05-22 11:22:39

--- In boost_at_y..., <boost_at_y...> wrote:
> 
> Hello,
> 
> This email message is a notification to let you know that
> a file has been uploaded to the Files area of the boost 
> group.
> 
>   File        : /threads/threads2.zip 
>   Uploaded by : williamkempf_at_h... 
>   Description : Temporary refactoring of Boost.Threads. 
> 
> You can access this file at the URL
> 
> http://groups.yahoo.com/group/boost/files/threads/threads2.zip 
> 
> To learn more about file sharing for your group, please visit
> 
> http://help.yahoo.com/help/us/groups/files
> 
> Regards,
> 
> williamkempf_at_h...

Threads2.zip is an update to the Threads.zip and the Boost.Threads 
library.  It's an experiment in refactoring the design to allow for 
faster implementations, and as such is not complete and I'm posting 
only for input on whether or not this is an idea worth pursuing.

Changes:

1) Changed operator bool() to operator const void*(), hopefully for 
the last time ;).

2) Added timeouts for specific times, much as the timespec timeouts 
used by pthreads.  This required functionality currently not 
available in standard C++ so I've included a preliminary "xtime" 
library with minimal functionality.  This form of timeout allows for 
nanosecond precision (depending on the capabilities of the underlying 
architecture/library).  The "duration" timeouts have been left as is, 
i.e. they take milliseconds as a parameter.  Changing this to use 
seconds and nanoseconds just results either in ambiguities or in a 
harder to use interface for such timeouts, so I think the "precise 
time" timeouts are a good compromise on this.

3) Removed fast_mutex.  The same functionality is now found in 
mutex.  See 4.

4) Factored out mutex into three types: mutex, try_mutex and 
timed_mutex.  This allows for the fastest possible implementation 
based on the needs for the various lock types.  Hopefully this will 
alleviate some of the concerns over the speed of the mutex types, 
especially for pthread implementations.  One result of this factoring 
is that all the mutex types now have an unspecified locking policy, 
meaning attempts to recursively lock the mutex by a single thread 
will result in undefined behavior instead of in lock_error exceptions.

One should note that the documentation has not been updated to 
reflect these changes yet.  Further, only the test harness has been 
modified compile (and work correctly) while the sample programs will 
fail to compile.  Both of these will be fixed only after discussion 
about the changes made.

I'm most interested in opinions about the factoring of mutex.  If 
this sounds like a good idea then we should also factor out 
recursive_mutex in the same manner.  I'm a tad concerned with the 
length of names produced by this, though: recursive_mutex, 
recursive_try_mutex and recursive_timed_mutex.  Would the names 
rmutex, try_rmutex and timed_rmutex be acceptable in this case?  Or 
are there other names that would work better?