macOS Shared Memory thread synchronization problem

dude5552 said:

I have 2 global variables var1 and var2. I init them to 0 at the beginning. Then i start two threads t0 and t1 and to synchronize their execution on t0 i am incrementing var2 and waiting for var1 to become 10 and on t1 i am incrementing var1 and waiting for var2 to become 10 .. Since both t0 and t1 are incrementing var1 and var2 while waiting for the other to become 10 ...
What i have noticed is that for t0 var1 is always 0 and for t1 var2 is always 0 so they wait on each other forever...
Does anyone have an idea why?
I start both threads t0 and t1 at the same time...t0 is running on core 0 and t1 is runnning on core 1 in a multiprocessor setup..
I tried to print values var1 and var2 at different intervals .. i always find t0 sees var1 =0 and t1 finds var2=0...

Click to expand...

Multithreading is difficult, and so is reading other people's minds. I am quite good at the former, but really bad at the latter, so I have no idea what you are doing wrong. You seem to be bad at multithreading and good at reading minds, or you would have written something that actually could tell us what you are doing and what you are doing wrong.

How are your threads sharing these variables? From your description is sounds like they aren't. Even if they are how are you guaranteeing atomicity of operations?

I think we ought to wait for the OP answering what code he has written.

Basically, it is about a concept often called thread-safe. It has several part, but the OP got bitten really early on. Good thing, because these errors can be among the really difficult ones to iron out. The system simply behaves in unpredictable ways.

Assume we have a variable var1 defined as:
...
int var1;
...

And then add two threads t0 and t1 reading and writing to that variable.

One of the thread might have this code snippet.

...
while ( true)
{
if (var1 > 10)
{
.... do something
}
... do some other things
}

The compiler "knows" that inside the while loop, no-one modifies var1, so it can temporarily hold the value inside a register. There is no guarantee that if another thread modifes var1, that this thread will notice it.

In c the way to tell the compiler to at least consider this situation is by adding a little something to the definition:

...
volatile int var1;
...

the little word volatile is an order to the compiler that some "other hardware" might modify the variable and that seemingly meanigless tests should not be optimized out. This is not really supposed to be used for thread synchronization, often it will simply make things work. (That is, until you end up on a compiler / hardware where this is not true). One reason why it might not work is that any operation, say

...
var1++;
...

is not guaranteed to be atomic. With atomic operations we mean operatins that are done to completion without beeing interrupted in the middle. On many architectures var1++ happens to be atomic for ints, but you actually have to check your compiler and hardware.

It cold happen that if two threads does var1++ at the same time the value is not incremented twice, but could instead be totally trashed. Most often it will actually work, but once in a time it might only increment once. And in very special circumstances, it might instead end up having some other value.

In objective-c, there is the volatile keyword, but again it is not thread-safe, in that two threads updating the same variable will not be guaranteed a result.

The solution instead, is given in the first reply where there are references to the atomic, threadsafe primitives that you should use.


// Gunnar

ghellquist said:

I think we ought to wait for the OP answering what code he has written.

Click to expand...

Not going to happen. Both the waiting and the answering

I wouldn't be surprised if he did this:

dude5552 said:

Before i wrote in x86 64 bit assembly...

Click to expand...

Why

Some points:

1) Post full code that can actually be compiled and tested
2) Use the code tags
3) You're "variables" seem to be registers. These are core local...

When ever two threads use the same variable you need to use a locking mechanism or the result is going to be unpredictable, in a case where you use a threading library such as pthreads there are mutex locks for this.

dude5552 said:

I am using fork to create threads...
Is there a problem with that ... I though underneath it all it is Unix BSD related code right....

Besidges I am not sharing variables... r10 and r11 below to individual CPU registers... they are only pointing to locations which are shared....

Click to expand...

If you use fork() then they are not threads, but processes. Threads share address space, processes don't. In regards to your second paragraph, a shared resource is probably a better term. You need to make sure that each process handles the resource in one atomic operation, hence the lock. Doing this in assembly however, means that you are on your own as far as I'm concerned lol.

If you are interested, this is how gcc implements a mutex lock:

http://comsci.liu.edu/~jrodriguez/testandset2.html

Fork does not create threads. It creates separate processes which receive a copy of memory from before the fork but is separate after that, so changes made in one process will not be seen in the other.

dude5552 said:

Right ...
Now assume that i allocated a big chunk of memory g_mem1

Click to expand...

How did you allocate g_mem1? Processes do not share address space.

dude5552 said:

g_mem1=(UINT64)mmap(<SOMETHING HERE>);

Click to expand...

What is the <SOMETHING HERE>, because what you pass to mmap() will influence how memory is shared between two processes.

Divide the problem.

First, do the two processes actually share memory?

Let t0 store a magic number next to its variable. Check in t1 if that magic number is there. If not, the problem clearly is that they are not sharing memory.

// Gunnar

What about
MAP_PRIVATE Modifications are private (copy-on-write)?

Try MAP_SHARED instead
// Gunnar

I have to ask...
What are you doing that needs to be this low level??


I have a poor imagination when it comes to cases when you are running on a platform that has gcc and the processor speed and optimizations to make C possible, but you prefer to do multi-threading from the ground up in assembly. I believe that C (with optimizations) can, and will, write better assembly then 99% of programmers could ever come up with.

jared_kipe said:

I have to ask...
What are you doing that needs to be this low level??


I have a poor imagination when it comes to cases when you are running on a platform that has gcc and the processor speed and optimizations to make C possible, but you prefer to do multi-threading from the ground up in assembly. I believe that C (with optimizations) can, and will, write better assembly then 99% of programmers could ever come up with.

Click to expand...

I wouldn't say the compiler would produce better assembler code than I could, given an infinite amount of time, but I can write ten times better algorithms in a high level language than I could in assembler. And I can call code written by others who spent ten times more time on it than I could reasonably justify.

gnasher729 said:

I wouldn't say the compiler would produce better assembler code than I could, given an infinite amount of time, but I can write ten times better algorithms in a high level language than I could in assembler. And I can call code written by others who spent ten times more time on it than I could reasonably justify.

Click to expand...

One could argue that 'maintainable' is 'better'..