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?