How to share data between threads

How can a message be sent from one thread to another without using a shared object such as a message queue or a mailbox?

Message queue or mailbox is a service provided by OS, not the part of the application. Those services are designed to operate correctly; the actual change of the ownership is hidden under the hood and not visible to the application programmer.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Ah, so when you wrote "I avoid the communication between the threads via the shared objects" what you actually meant was "I avoid the communication between the threads via shared objects _designed_by_myself_as_part_of_my_application_." You've no objection to using shared objects written by somebody else as part of the OS.

What I suggest is the communication by message passing instead of using the shared data. The messaging is completely different concept; it is clear, safe and free from the priority problems. The particular details of the inner implementation of messaging are irrelevant; is the business of the OS.

VLV

It's an approach that does inter-process communication using shared objects in a different way. It too has it's drawbacks (shuch as higher overhead).

When you are sending a message to this newsgroup replying to my message, is your message shared object or not? I say not.

VLV

Is it an irrelevant issue if the OS has mailboxes with finite or infinite capacity :-).

With a finite capacity mailbox, you still can end up in priority inversion problems. When the mailbox is full, due to the receiver being prevented from processing data due to the CPU load by a middle priority thread, the sender can either block or the mailbox write can return MAILBOX_FULL error and the sending application must do some special processing.

Any priority inheritance systems are not acceptable in many cases due to unpredictable latency issues.

Paul

In most cases, it isn't. "Shared access" is a fallacious notion that is completely replaceable by a solution involving data ownership, like message passing.

Higher processor and memory overhead (which doesn't even matter in most cases), but lower developer overhead.

This assessment is based on the assumption that operating systems can work magic, i.e. that it can do things that the processor on its own can't do. Message passing works by sharing memory between the process and the OS. You're just passing the problem on to somebody else (who has to write the OS).

I've been pointing that out this whole thread, but the point seems to be repeatedly missed.

Somebody else who doesn't actually know what your precise requirements are and has to design something for a general case.

If MP is part of the OS and not build on top of a shared-memory OS, I see no overhead in the OS and very little for the developer.

But with MP you should follow a more OO approach where you hide data (attributes) and get/set them with messages (methods).

A task is also an OS object you have to rely on. The OS handles sharing the CPU among all threads, so why not rely on the OS to handle data access.

Note: The OS objects are only shared between a thread and the kernel, never between threads, and since either the OS or an application thread owns the CPU there is no problem accessing these shared objects.

Vishal:

You can probably get good answer or maybe definite solution if you would be elaborating bit more. Whats your OS? and do you consider to do while using provided OS services or you want to stick to application level?

For application level shared memory with mutex or semaphore is the way to go. But in order to grant permission to 'only 2 threads' you got to do little extra stuff.

And if you want to use OS provided services then again question is what platform? Assuming you want to use some POSIX platform then mailbox, sockets, file I/O or messaging system should do the job.

ali