Click here to Skip to main content
15,038,237 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
I am looking at IPC between .NET and C on Linux. I have managed to get some shared memory working using:

C shm_open and mmap 
C# MemoryMappedFile

I need a mechanism though to be able to synchronize the changes between my .NET application and the C application and i cannot find a way to have a shared lock mechanism.

I have looked at named semaphores (but this is not supported on linux in .NET). I have looked at named Mutex (but this is not supported in C on linux). I have looked at creating a shared memory area for a phtread_mutex_t object in C on linux which works but i have no way to map that to anything in the .NET environment.

Does anyone know of a way I can do this or maybe get the pthread_mutex_t method working?

What I have tried:

Tried Named Semaphores
Tried Named Mutex
Tried sharememory for pthread_mutex_t
Updated 26-Aug-20 14:32pm
Afzaal Ahmad Zeeshan 24-Jun-20 18:09pm
Although it is highly unlikely that Microsoft would support or provide support for C or anything like COM etc. The focus now is more on "getting-things-done". Also, .NET 5 is still in preview so several libraries/packages will not be available for use, and that means most of .NET related work that helps in this area does not work.

Have you tried creating a bridge between named semaphore/named mutex? :-)
chrispdraycott 25-Jun-20 4:56am
If you think .NET 5 has restrictions not yet implemented then I am happy to explore .NET Core 3.1 as well.
Not quite sure what you mean by a bridge but in the C world I can have a named shared mutex in shared memory but I dont know how access that as a syncronization mechanism in .NET.
Garth J Lancaster 25-Jun-20 3:17am
Have you thought about either polling the shared memory for a 'signature' or 'sequence ID' at the start of the block or perhaps using a pipe between the two processes as a 'signalling' mechanism ?

The only other thoughts I had, likely 'too heavy-weight', use a small message protocol between the two systems - ZeroMQ for example (not RabbitMQ)
chrispdraycott 25-Jun-20 5:02am
Thank you for your suggestions.

Yes I have looked at a value at the beginning of shared memory for indicating whether one process is writing to memory but then you get into how do you wait for access and ensure you get access correctly. If one process is updating shared memory every second for example it will be keeping the value active quite often and so you would need to be polling/checking the value in the other process at a high frequency to ensure you get in there to change it. It might be possible but not ideal.
I am surprised that its not been thought about in the linux world. Wouldnt be a problem on windows which is no surprise!! Surely there must be a requirement for low level applications written in c/c++ that need to communicate with high level applications built in .NET.

The reason I want to go Shared memory is for speed. I dont want to be using sockets or passing data to and from applications. So dont want too heavy-weight.

Member 13545882 6-Aug-21 10:04am
You can create two shared memories for the two appa. App1 can only read mem1 and write mem2, app2 can only read mem2 and write mem1, so you don't need mutex or something like that, it works like a pipe.

1 solution

Using a byte or two in shared memory as a variable for a state machine defining which part C / .Net gets access at what times is most likely your best option.

Assuming you have a multi-thread CPU at your disposal, there is no great difficulty having the C code doing really fast polling and basically chewing up a CPU core full time on its own with appropriate processor affinity/process priority.

If possible compartmentalize the functionality between C and .Net so that you are not always going back and forth changing states at high speed. Aim to have the C do the more time critical things, and the .Net, the more clever but lazy catchup just in time stuff.

The shared memory state variable is usable as you please under your full control - e.g. having a state defined where the C is writing one part of shared memory while the .Net writes another part can be accommodated. Just define multiple states/state transitions to give the read/write access that best suits your application!

Then use a .Net asynchronous Task to poll the state variable in a loop with "await Task.Delay(nnn) and a case statement to distribute Tasks to execute the various states using .Net functionality. That way you leverage the multiple threads/cpu cores that .Net gives you by default. This should give time a granularity down to 20 milliseconds or so.

If you are looking at microsecond kind of back and forth between C and .Net in shared memory you are out of luck I think and need to rethink the code design.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900