[ACCEPTED]-How do I synchronize two processes?-named-pipes

POSIX semaphore is the way to go. Since you want to share 5 the same semaphore across processes, you 4 need to use a named semaphore.:

A named semaphore 3 is identified by a name of the form /somename. Two processes 2 can operate on the same named semaphore 1 by passing the same name to sem_open(3).

Semaphores and Mutexes/condition variables 69 are good, very high-performance primitives 68 which are appropriate for use in between 67 threads or in between processes.

All of these 66 are based on the idea (and usually, on the 65 reality) of test-and-set or other atomic 64 operations performed upon shared memory.

If 63 you expect to distribute your processes 62 over the network, then semaphores and mutexes 61 may not be right for you--they only work 60 on a single machine. Pipes and sockets 59 are more generally network-extensible.

A 58 brief summary of mutexes, condition variables 57 and semaphores:

Mutexes

A mutex is a primitive which 56 can be either locked, or unlocked. The 55 process/thread which locked it must be the 54 one to unlock it. This ownership aspect allows the 53 operating system to apply some interesting 52 optimizations, such as priority inheritance 51 and priority ceiling protocol (to avoid 50 priority inversion). however, the mutex does not 49 have a count associated with it. You can't 48 lock an already locked-mutex, in general, and 47 retain memory that it was "locked twice" (there 46 are some extensions that allow this, I think, but 45 they are not available everywhere)

Condition Variables

A mutex 44 is great for...well, MUTual EXclusion. But 43 what if you need to block on a condition 42 associated with the object to which you 41 have mutual exclusion? For this, you use 40 a condition variable, or CV. A CV is associated 39 with a mutex. For example, say I have a 38 queue of input data which my processes want 37 to access. One grabs the mutex so it can 36 look at the queue without fear of interference. However, it 35 finds the queue empty and wants to wait 34 for something to come in on the queue. It 33 therefore waits on the "queue not empty" condition 32 variable. The interesting part here is 31 that, because the CV is associated with 30 the mutex, the mutex gets automatically re-acquired once the condition 29 variable is signalled. Thus, once the process 28 wakes up after waiting on the CV, it knows 27 that it has exclusive access again to the 26 queue. What it does not know is whether the 25 queue really has anything on it--perhaps 24 two processes waited on the CV--one thing 23 came in--and the first priority got in and 22 dequeued the "thing" before the second thing 21 woke up. Thus, whenever you use a CV, you 20 need to RECHECK the condition, like this:

mutex_enter(m);
while (! condition) {
   cond_wait(m, c); // drop mutex lock;  wait on cv;  reacquire mutex
}
//processing related to condition
mutex_exit(m);

Semaphores

OK, that 19 is mutexes and condition variables. Semaphores 18 are simpler. They can be incremented and 17 decremented by any processes. They have 16 memory--they count--so you can use them 15 to determine how many of a condition have 14 occurred. Not so with condiiton variables. Also, because 13 semaphores can be decremented by one process 12 and incremented by another, they do not 11 have the ownership aspect--so no priority 10 inheritance, no priority inversion avoidance 9 is possible.

Now, finally--all of these mechanisms 8 require shared memory for an efficient implementation. This 7 may be fine for you, but be aware--if you 6 believe that your appliction may eventually 5 be distributed, then mutexes, condition 4 variables and semaphores may not be for 3 you. Pipes and sockets, while much higher-overhead, have 2 the possibility of being extended over the 1 network fairly straightforwardly.

Use the POSIX semaphores.

0

Since you only need a semaphore count of 1 one, a mutex suffices.

I think if we want to synchronize the multiple 3 running processes, then we can use a very 2 easy technique called file locks.

Please 1 refer to this article for more details: http://blog.markedup.com/2014/07/easy-mode-synchronizing-multiple-processes-with-file-locks/

I assume that

...that is shared between 34 two applications?

means that you want these 33 two things to be running as separate processes? If 32 that's not true, and they are running as 31 a single process (with multiple threads), then 30 the suggestions of semaphores and mutexes 29 are the best option and should be quite 28 straightforward.

Note that the answer will 27 depend on exactly how you're accessing this 26 hardware. For example, if it's exposed through 25 a file then normal file locking can be used.

However 24 if you're attempting to synchronise access 23 to the hardware across two processes that's 22 a different matter. I guess the first thing 21 to say is that it's going to be easier to 20 synchronise, if you can, to have a single 19 process in charge of accessing the hardware. In 18 this model you might have one process that 17 acts as a server for the hardware - accepting 16 requests from other processes and performing 15 the reads and writes on their behalf. Just 14 about any form of interprocess communications 13 will be suitable, but for simplicity something 12 like the message queue (link) may be appropriate 11 with some appropriate data structure (eg. a 10 flag to indicate whether it's a read or 9 write operation, offset from base address 8 of your hardware, number of bytes, buffer 7 (in case of a write))

If putting all of the 6 direct hardware access into a single process 5 isn't appropriate then you'll have to use 4 a proper synchronisation scheme. I would 3 investigate the use of either file locks 2 (and implement a rudimentary mutex scheme), or 1 using named semaphores (as albertb has suggested)