How to share data between threads

This isn't a C++ question. It's an OS question, and you haven't told us what OS you're using, or what processor, or anything else that may be pertinent to the answer.

If the processor can do an atomic write to the variable, and if the OS gives your two threads a common memory space, then you may well just be able to write to the variable -- whether this is a good idea or not (often it's not, but when it's a good idea it's a _good_ idea) depends entirely on your application.

At any rate, it should be in your OS documentation.

template class ATOMIC { T t; SEMAPHORE semaphore;

public: void Get(T&x) { semaphore.Enter(); x = t; semaphore.Leave(); };

void Set(const T&x) { semaphore.Enter(); t = x; semaphore.Leave(); } }

And so on, so forth....

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

You create a global object of some sort that either provides synchronization itself or you provide synchronization.

And I don't want to pay taxes or die. Life's like that.

You create a global variable and control access to it with a synchronization tool.

Thanks to all for the solution. You guys mean to say that there is not way to create a variable that share between only two threads?

That's exactly what they mean. It's true, but the details can be hidden inside a language implementation, like with the Java synchronized objects, or the C++ template class that V.V. offered.

Clifford Heath.

At least I try to use atomic operations whenever possible.

If you are forced to use some OS synchronization primitives, there is always the risk for priority inversion problems, if there are moe than two threads trying to access the same resource.

Paul

An RTOS should support mechanisms like the priority inheritance or priority ceiling in order to handle this kind of problems. Of course, again, this depends on the OS Vishal is using.

Giovanni

I have used various RT kernels successfully for decades, before I even heard of the "priority inversion problem" on some NASA probes on Mars.

Priority inheritance etc. systems just hide some bad architectural errors.

Paul

This can be true, it is possible that the system can be designed to not need such mechanisms at all).

Anyway, in the described scenario, a simple mutual exclusion, the priority

inheritance mechanism can prevent the kind of risk that you posted regardless the number of threads accessing the protected zone.

Giovanni

On a hard real time system you assign priorities to tasks based hopefully on some logical reasoning in that one task should have a priority higher than another. If you then allow your system to temporarily but largely non-deterministically change these priorities, however fleetingly, then you have allowed the prioritisation reasoning to be breached. IMHO any system that relies on priority inheritance in this way is in effect no longer behaving as the designer intended.

Priority inheritance does nothing to 'prevent' inversion problems, it just minimises its potential effects - in a non deterministic way. If your system is not hard real time, or the tasks that use priority inheritance are not critical, then it probably does not matter.

Small embedded systems do not require a priority inheritance system - just a good design.

on

than

you

system

just

are

just a

I largely agree that the P.Inheritance or the P.Ceiling are not magic bullets, those are just tools that the OS provides to the system designer. Of course no tool can help a wrong design.

I agree less on the "non deterministic way".

About this subject, I found the following articles very interesting:

Giovanni

One of the problems is that people try and apply absolute definitions to terms such as mutex, binary semaphore, and counting semaphore - whereas each vendor uses their own terms and definitions. These items are not defined in the dictionary.

For example the second referenced article states "Unfortunately, many sources of information, including textbooks, user manuals, and wikis, perpetuate the historical confusion and make matters worse by introducing the additional names 'binary semaphore' (for mutex) and 'counting semaphore.' ". By whose definition? FreeRTOS.org has both binary semaphores and mutexes, and draws a distinction between the two. It also has counting semaphores, named such to make the distinction from their binary cousins.

Also, the statement "Fortunately, the risk of priority inversion can be eliminated by changing the operating system's internal implementation of mutexes" is made without any form of explanation or example. This is, in my opinion, a myth and factually incorrect. If this statement is referring to either priority inheritance or priority ceiling algorithms then these mechanisms can only lessen the effect of priority inversion and not 'eliminate' it. Also, their use makes the behaviour of the system extremely difficult to calculate (trying to avoid the 'non deterministic' statement from the previous post).

Whenever there is anything shared between the two threads, I always use the OS synchronization mechanism. It is not a good idea to rely on the atomicity of *any* operation, because it is VERY system dependent. Also, I avoid the communication between the threads via the shared objects. Instead, I use the OS message passing mechanism, which is guaranteed to be atomic and free from the priority lockup. Albeit somewhat inefficient, this discipline allows developing big projects and keeping them manageable.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

The key point in RT system design is finding what jobs can be moved to a _lower_ priority level, without harming the total system performance.

Trying to detect the most critical part and increasing the priority will just end up in chasing your own tail.

Paul

How can you know for sure what is atomic and what is not? The atomicity can be implicitly assumed only for the local objects belonging to the one thread.

The "bad architectural mistakes" are inevitable in the course of the development. Especially as the new features are added when the project has already gone so far. The less the programmer has to know about the system architecture in the order to be able to add a new feature, the smaller the software changes have to be - the better.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Of course I look at the instruction set if it contains memory referenced increment/decrement instructions and if these are implemented by a read/modify/write memory access cycle.

Anyway, a good RT design would rely on data ownership by a controlling process, not by shared access by some unreliable means.

Paul

This is just the simplest part of the problem. There are also the deferred and/or combined writes, cache, memory and DMA coherency issues and such. Even if the access is implemented as the single read or write CPU instruction, it can be split into several bus cycles with the interrupts or DMAs allowed in between.

Shared access is the necessary evil. If there is a need for it, the access should always be protected by the means provided by the OS. It not safe to rely on the implicit atomicity of any operation.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

How can that not be using a shared object?