Date: 2001-05-22 15:09:04
--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 12:22 PM 5/22/2001, williamkempf_at_h... wrote:
> >... One result of this factoring
> >is that all the mutex types now have an unspecified locking
> >meaning attempts to recursively lock the mutex by a single thread
> >will result in undefined behavior instead of in lock_error
> Seems like a reduction in safety. Is it costly to continue to
> lock_error exceptions?
Many threading libraries, and in this case pthreads is one, leave the
locking strategy as undefined. The newer pthreads standard will add
a checked variant that is gauranteed to return an error when
recursively locked allowing for a simple implementation that throws
in this case. However, for libraries that don't allow for checked
semantics, including the current(?) pthreads standard, there is no
thread safe and efficient manner in which to detect this error. This
is what lead to the less efficient mutex in the Threads.zip, which
was criticised by those used to pthreads usage. Something must be
compromised here and it may be best to compromise a small bit of
safety here in order to insure efficient implementations.
> >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.
> OK with me, but I'm not a threading expert. Seems a bit clearer
> mutex types with three lock types.
If you look at the factoring there's still a mutex type with three
lock types. The timed_mutex supports all three lock types and is
thus equivalent to the old mutex type. The motivation for the
factoring is to allow the user to pay for only what he needs. A
timed lock will require a much more complex mutex type both in terms
of both memory and speed. If a timed lock will never be used the
programmer should not have to pay the penalty of this more complex
mutex type. This was motivated by the timing comparisons between the
old boost::mutex and straight pthreads usage.
> > I'm a tad concerned with the
> >length of names produced by this, though: recursive_mutex,
> >recursive_try_mutex and recursive_timed_mutex.
> They don't seem that long to me. And better that the more
> By the way, I have now used Boost.threads in one test program (with
> bounded queue) and one real application. Very good results with
Good. What did the "real application" do, just out of curiosity?
> The one need that keeps coming up is thread-safe counter known to
> least 32 bits.
If we were to limit it I'd think it would be better to say at least
sizeof(int) bits. I'm sure there are some architectures that would
allow for efficient 16 bit atomic operations since an int is 16 bit
there, while 32 bit atomic types would have to rely on the much
slower mutex. At this point atomic_t could fit this bill simply by
changing the documentation (i.e. the current implementation fits the
bill any way).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk