Boost logo

Boost :

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
> 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
> 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
> 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
> after releasing it, before one of the waiting threads manages to acquire

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
> 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:
> -----------------
(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
(that is another reason why I dislike the current thread obj design)


Boost list run by bdawes at, gregod at, cpdaniel at, john at