Re: New file uploaded to boost

From: williamkempf_at_[hidden]
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 
policy,
>  >meaning attempts to recursively lock the mutex by a single thread
>  >will result in undefined behavior instead of in lock_error 
exceptions.
> 
> Seems like a reduction in safety.  Is it costly to continue to 
throw 
> 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 
than one 
> 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 
abbreviated 
> suggestions.
> 
> By the way, I have now used Boost.threads in one test program (with 
Jens' 
> bounded queue) and one real application.  Very good results with 
both.

Good.  What did the "real application" do, just out of curiosity?
 
> The one need that keeps coming up is thread-safe counter known to 
hold at 
> 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).

Bill Kempf