[boost] Thread library with BOOST_HAS_PTHREAD

From: Shimshon Duvdevan (shuki_duv_at_[hidden])
Date: 2003-01-30 18:55:23

Hi all,

When boost threads library is configured with pthreads, threads are created
using the following code:

  res = pthread_create(&m_thread, 0, &thread_proxy, &param);

However, on Solaris this implies the default contentionscope of
PTHREAD_SCOPE_PROCESS (vs. PTHREAD_SCOPE_SYSTEM). I didn't build boost
threads library on Solaris, but code using pthreads as above results in
situation where only one thread at a time can be active (SunOS 5.5.1). I.e.,
a kind of cooperative scheduling.

In order to allow threads to run simultaneously on a multi-processor
machine, I had to write the following code (in main()):

  pthread_t threads[4];
  pthread_attr_t attr;
  const int args[] = {1, 2, 3, 4};

  pthread_attr_init(&attr);
  pthread_attr_setscope(&attr, PTHREAD_SCOPE_SYSTEM);

  for (unsigned i=0; i < sizeof(threads)/sizeof(pthread_t); ++i)
    pthread_create(&threads[i], &attr, &func, const_cast<int *>(&args[i]));

  for (unsigned i=0; i < sizeof(threads)/sizeof(pthread_t); ++i)
    pthread_join(threads[i], NULL);

Note the "&attr" in pthread_create call. If pthread_attr_setscope is
omitted, only thread 1 executes (since func() never blocks).

Can anyone verify the supposed boost threads library behavior on a
multi-processor Solaris machine? Is this behavior the intended one? Perhaps
a bug fix is necessary.

On a side note, library documentation says that "The result of a race
condition may be a bit pattern which isn't even a valid value for the data
type." I have seen such claim in many places, but is there a modern
architecture that actually allows that? (I tested on a Sun machine mentioned
above, and memory cell is never garbled.)

Thanks,
      Shuki