Thread: mutex necessity

I wonder wether pthreads can share variables safely, without using mutex, in the following special cases:
(1)
a structure or array is shared but each single element of the array, or field of the structure, is not shared.
Probably it is also necessary the assumption that these data are extern or static
Example :
pthread 1 uses only Struct[0].field1 , Struct[0].field2 and Struct[1].field3
pthread 2 uses only Struct[1].field1 and Struct[0].field3

(2)
from a certain moment on I am sure that some data are only read by (and not written by) all threads
Probably it is also necessary the assumption that these data are extern or static
Example:
Struct[whatever].fieldAny can be read by any thread but no one will write it

(3)
Other special question:
can pthreads share a mutex directly or do they have to access it via separate pointers?
Example:
pthread1 calls pthread_mutex_lock(&mutex) ... pthread_mutex_unlock(&mutex)
pthread2 calls pthread_mutex_lock(&mutex) ... pthread_mutex_unlock(&mutex)

or is it necessary that
main thread runs mutex1=&mutex mutex2=&mutex then creates thread1 and thread2 where
pthread1 calls pthread_mutex_lock(mutex1) ... pthread_mutex_unlock(mutex1)
pthread2 calls pthread_mutex_lock(mutex2) ... pthread_mutex_unlock(mutex2)



Thank you for help

3) They can call the same mutex. I believe it is guaranteed that only one will get the lock.

2) Reading a variable doesn't need syncrhonization. If two threads require the same variable to read, then the bus controller will serialize the "require" and give the values to each thread. The problem is with writing.
A classic example
Thr1: r = 2;
Thr2: r = 1;

Both threads read r. It doesn't matter who reads first. It matters who writes last. That will determine r value. If you have:

Thr1: r+= 2;
Thr2: r = 1;

Then the write (for the same variable) makes it necessary for synchronizing the oprerations.

1) So you can read Struct[0].field with Thr1 and Struct[0].field2 with Thr2 and change their value safely. Since the data is in different memory location.
In general, you can safely read Struct[0], since its value cannot be changed, and safely read/write its struct fields since they aren't shared, but each thread reads different memory locations.

1) There are no portable guarantees of safety due to word tearing - which Posix does not address. There are ways to improve (portability) safety, but there's still no portable guarantees of safety. More details at this comp.programming.threads thread: http://groups.google.com/group/comp....a9c0ee17e390c/

2) As per 4.10 of the Posix standard, this is ok - as long as the data was initialized or set prior to the threads being created. http://www.opengroup.org/onlinepubs/...bd_chap04.html
>> Probably it is also necessary ... that these data are extern or static
No.

3) Both or OK. What you must never do is make a copy of the pthread_mutex_t object itself. You can make copies of the pointer and use them.

gg

[QUOTE=Codeplug;767583]1) There are no portable guarantees of safety due to word tearing - which Posix does not address. There are ways to improve (portability) safety, but there's still no portable guarantees of safety. More details at this comp.programming.threads thread: http://groups.google.com/group/comp....a9c0ee17e390c/

The point you move is very interesting but astonishing. So you're telling me that on a Linux platform any data smaller than (I guess) 4 bytes is not safe? Or even a 4 byte integer is not safe if put after a 2 bytes variable (if the compiler for some reason did not pad) together in a struct??!
Gosh

More specifically, you are in danger of having word-tearing if two threads write to adjacent memory locations, and both of those locations fit within the natural memory granularity of the processor.

Using non-standard compiler features can help mitigate this risk. For example, GCC's "__attribute__ (aligned(#))", or MSVC's "__declspec(align(#))" to force the compiler to align members to a particular granularity. You also have to be careful when using dynamic memory - for instance, malloc may not return memory that sufficiently aligned. There are non-standard functions for this such as the MS-CRT's _aligned_malloc().

Having said all that - a memory-access design such as 1) will cause "false sharing" or "cache thrashing". This is when two threads are modifying data within the same processor cache-line - where each independent modification doesn't need to be "communicated" to any other cores.

Ideally, if thread 1 (T1) modifies a local data set 1 (S1), and T2 modifies S2, then S1 and S2 would be at least "cache-line-size" apart from one another.

Here's a good "cache 101" article. The "Cache Loading" section talks about false sharing. http://developer.amd.com/Membership/...eloper.amd.com

So in the end, a design such as 1) should be avoided.

gg

>> ... have size multiple of processor memory granularity?
*And* are aligned to it as well.

>> But still it can be very inefficient...
Correct.

Just to re-iterate David Butenhof's position:
"The best strategy would probably be to say that AN array or A structure is an "atomicity unit"."

In other words, just don't write to individual struct or array members across multiple threads. If re-designing and re-writing *really* isn't an option - then you can use compiler support to ensure proper alignment and padding of struct members. Ways to this with GCC are discussed in this thread: http://groups.google.com/group/comp....0feda6bf72801a

gg