AnishaKaul wrote:Since in their case they haven't got signals yet, so what can be the possibilities of synchronization in their case?
I have heard the RTAI "is" commonly used. So, they must be having a workaround for the missing signals?
Well, I was not precise. You don't need signals, but you need the functionality they provide.
The point is, when a signal arrives, it's handler get called. So when a signal delivered, the process will execute code that the sender expects. You have other methods for that, sure. The point is, you have to stop or make faster a process (or use any other methods like handler), so when the other process wants to talk to it, it must be at a known state.
For example, let's say there's A and B, executing instructions:
A: qwerty
B: asdfgh
for proper functioning A has to execute "e" when B is executing "s", else their communication will be a mess. With signals you can put "erty" in a signal handler in A, and insert a send signal before "s" in B (it's not necessarily the best solution, but correct). This method mostly used when a process can have several independent "discussions" with other processes.
You can also use a busy-wait for that. In this case before "e" you insert an infinite loop (which is infinite because it's expression not modified inside the loop by A). Now in B, before "s" you put an instruction that modifies A's exit criteria (involves IPC or shared memory, since A and B have different address spaces). So when A executes "w", it won't continue to "e", rather wait in a loop. When B executes it's modifier instruction, it will allow A to continue, and go to "s". This way again "e" and "s" will run simultaneously. The busy-wait's exit criteria is usually a boolean and often helped by hardware (like x86's bts (bit test and set) instruction or cmpxchg (compare-and-exchange) etc.).
Although busy-wait look simpler, I would not recommend it, as it's eating up precious cpu time (hence the name busy).
Because of similarities, this point of instructions (after which they will run synchronized) is often called a randezvous point.
It's also important to understand how critical section (mutual exclusion) and synchronization related. Let's assume we have two variables on shared memory. Only one process allowed to access them at a time. For this let's say we have instruction 1 (writing value to variable #1) and 2 (writing to variable #2). We have A and B like
A: 1212
B: 1212
This means that they both wants to write the variables at the same time, which is bad.
11
22
11
22
With synchronization, you can make them like
A: b1212
B: 1k212
(where b means busy-wait, and k is for kill (like in send signal, but remember, it's just an analogy)). Now before A can execute 1, it will stuck in a loop. So when B executes 1, it's okay. When B finishes, it notifies A that it can continue, and go on with 2. When A executes 1, B is executing 2, so no problem here:
1x
21
12
21
x2
There's even more, but it's far beyond the scope of a post. There's many articles and books on the topic.
Few keyword to search for: randezvous point, semaphores, spinlocks, monitors (special language constructions), Dijkstra's sleeping barber problem.
