On 10/27/07, Florian Weimer <[EMAIL PROTECTED]> wrote: > > Anyway, not reordering across function calls is not sufficient to get > sane threading semantics (IIRC, this is also explained in detail in Hans > Boehm's paper).
Hello Florian, In Hans Boehm's paper the following issues are identified: 1. Concurrent accesses of variables without explicit locking can cause unexpected results in a multithreaded context (paragraph 4.1). 2. If non-atomic variables (e.g. one field of a bitfield) are shared over threads, and these are not protected by explicit locking, updating such a variable in a multithreaded context is troublesome (paragraph 4.2). 3. If the compiler performs register promotion on a shared variable, this can cause undesired results in a multithreaded context (paragraph 4.3) And this thread started with: 4. If the compiler generates a store operation for an assignment statement that is not executed, this can cause trouble in a mulithreaded context. My opinion is that, given the importance of multithreading, it should be documented in the gcc manual which optimizations can cause trouble in multithreaded software (such as (3) and (4)). It should also be documented which compiler flags must be used to disable optimizations that cause trouble for multithreaded software. Requiring that all thread-shared variables should be declared volatile is completely unacceptable. We need a solution today for the combination of C/C++ and POSIX threads, we can't wait for the respective language standardization committees to come up with a solution. Regarding issues (1) and (2): (1) can be addressed by using platform-specific or compiler-specific solutions, e.g. the datatype atomic_t provided by the Linux kernel headers. And any prudent programmer won't write code that triggers (2). And as you may have noted, I do not agree with Hans Boehm where he states that the combination of C/C++ with POSIX threads cannot result in correctly working programs. I believe that the issues raised by Hans Boehm can be solved. Bart Van Assche.
