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, ¶m);
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
