Re: [boost] Design and documentation of Boost.Threads

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2001-11-12 06:52:56

[...]
> Fairness and strongness
> -----------------------
>
> Missing from the documentation is a discussion of the three levels of
> increasingly-strong guarantees for mutexes, which parallel the same
categories
> for semaphores:
>
> 1. Weak mutexes.  When a thread unlocks a weak mutex and there are other
> threads blocked waiting on the mutex, the mutex may enter the unlocked
state
> for a short period of time until some thread locks it again.  The locking
> thread may not have been one of the threads waiting at the moment the
mutex
> was unlocked.
>
> Consider the following scenario with a weak mutex.  Thread A is in a loop
> where it repeatedly acquires the mutex, does something, then releases the
> mutex:
>
>   while (1) {
>     <processing outside of the critical section>;
>     boost::mutex::scoped_lock l(mtx);
>     <critical section>;
>   }
>
> If there are one or more other threads waiting to acquire the mutex,
thread A
> may monopolize the mutex, starving the other threads so that they *never*
> acquire the mutex.  This can occur because thread A may reacquire the
mutex
> after releasing it, before one of the waiting threads manages to acquire
it.

so what? why do you care which thread enters critical
section and does the mutually exclusive work?
fairness could only slow things down (e.g. "hot" thread(s)
would likely to do the work much faster than "cold" threads).

> Atomic reads and writes
> -----------------------
>
> I think a discussion is needed of why even reads and writes of variables
of
> primitive types may not be atomic, and that there is *one* type for which
> reads and simple writes are guaranteed atomic (sig_atomic_t).

static volatile sig_atomic_t vars only work with respect
to ONE thread and a signal-handler interrupting THAT thread.
this is purely single-threaded async-signal-safe thing that does
not support non-synchronized data (mem) sharing between
threads; it should always be synchronized!

[...]
> recursive_mutex.html
> --------------------
[...]
> scoped_lock.html:
> -----------------
[...]

http://groups.google.com/groups?as_umsgid=361B4FBB.D396A5DB%40zko.dec.com
(that is why I dislike both)

[...]
> thread.html:
> ------------
>
> Quote: "This includes completion of all thread cleanup handlers,..."
>
> Comment: What thread cleanup handlers?  Boost.Threads has no such notion.
>
> Quote: "if a thread object is destroyed without join() having first been
> called, the thread of execution continues until its initial function
> completes."
>
> Comment: This sounds scary.

;-) also, with current semantics the initial thread is something really
special:

http://groups.google.com/groups?as_umsgid=c29b5e33.0110071552.6aec4afc%40posting.google.com
(that is another reason why I dislike the current thread obj design)

regards,
alexander.