Hallo, the basic question after all is the question of visibility of any change by one thread to other threads. So, what I understood and assume from all written (your answers, links, documention) is from the higl-level C perspective:
1) Any pthread_mutex_unlock (mutex_exit) causes any modified data to be written / flushed to memory. Modified data is then visible to any other thread / cpu. If a later read access is under a mutex (after pthread_mutex_lock / mutex_exit) the data is for sure read from memory, so volatile is not needed here, as it is illustrated in the programming examples for cv_wait. 2) Because of 1) visibility is not an issue for buffers or data structures that are required to be a accessed under a lock for data consistency or program flow control reasons. 3) Updates to data types that can be read / written in a single (atomic) operation and that are not protected by a mutex are not sure to be visible to other threads by simply using the volatile keyword. Instead they become visible after instructions that imply a flush of registers, store buffers, caches to memory. What I read between the lines such instructions / actions are: - mutex_lock / unlock operations - spawning a new thread - terminating a thread - calling a function Visibility to a thread reading this data would require the volatile keyword. ----- Things described under 3) are of course only of limited value, e.g. for a single flag or error value. Any more complex types and operations like "flags |= ERROR_A" might have a more or less unexpected result. When a second thread is doing "flags |= ERROR_B" at the same time the final result might easily be "flags == ERROR_B" omitting the flag ERROR_A that was intended to be set by the first thread. Do you think 1) - 3) are correct? -- This message posted from opensolaris.org
