Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I want to do the following:

I have a number of computers. On each computer a programm will run. There is no centralized server.

The program can choose by defined criteria to give another computer specified data. While doing so, the other computer should not do the same. (A sort of 2 way synchronize)

Let's make an example. (C1 .. Cn are the programs running on different computers)

C1 sends C2 updated data. While processing is active, C2 should not ask C1 for update something else.

The idea was:

C1 sends a message to C2: PauseExecution() C1 sends to C2 items to be processed (updates some data on C2) C1 sends a message to C2: ResumeExecution(). C2 sends a message to C1: PauseExecution() C2 sends to C1 items to be processed (updates some data on C1) C2 sends a message to C1: ResumeExecution(). But now the biggest problem arises.

If C1 sends a message to C2 to Pause, and C22 sends at the same tiem a message to C1 to Pause, both would block.

There is no centralized server / shared memory for keeping a semaphore.

Is there another pattern which can be used, so that n computers will not block?

So this question is about algorithmic exclusion.

Or is there another workaround for this problem, if no semaphore or mutex can be used?

share|improve this question
Academic interest, or real world. If real world, is this really about file syncronization, or shared processing, or what is the end goal you are trying to accompish? – sdg Feb 13 '13 at 15:57
Real World: Database values should be synchronized. As both machines are independend it could occur that both machines try to send a line at same time which should be prevented. – Offler Feb 13 '13 at 16:07

The keyword here is distributed transaction. Hit google with that and you'll find plenty of possible ways, but as Karl already said a two-phased commit is the traditional solution.

Given that there is no central authority, it makes sense to assume nothing about the other systems until you get an acknowledgment from them that they agree to your plans (first phase). Only when all the involved systems agree do they perform the transaction / data sending / whatever (second phase).

Depending on the amount of transfers you have and the number of systems involved, you have to take a closer look at possible cases of starvation though. Let's say that systems A and B continually want to send data to system C and more or less bombard it with first-phase commits, i.e. they ask system C if it is willing to accept a file from them. If you now want a system D to send a file to C, it might never get an acknowledgment depending on the specific implementation details' fairness.

share|improve this answer

There are a number of well-known algorithms for this. Ricart-Agrawala appears to have the fewest issues. Basically, instead of commanding another system to pause execution, you pause your own execution, send a request, and wait for a reply before unpausing. Then you send another message when you're done executing the critical section. The different algorithms have different ways of avoiding deadlock.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.