0% found this document useful (0 votes)
52 views1 page

Atomicity

Atomicity is a characteristic of group communication that guarantees all-or-nothing delivery of messages to members of a group. It is desirable because it simplifies programming distributed systems by ensuring consistency. Implementing atomic broadcast is challenging because it must guarantee delivery even if some machines fail. However, atomicity is possible through algorithms that use acknowledgements and retransmissions to ensure all surviving processes eventually receive each message.

Uploaded by

Sunil Kumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
52 views1 page

Atomicity

Atomicity is a characteristic of group communication that guarantees all-or-nothing delivery of messages to members of a group. It is desirable because it simplifies programming distributed systems by ensuring consistency. Implementing atomic broadcast is challenging because it must guarantee delivery even if some machines fail. However, atomicity is possible through algorithms that use acknowledgements and retransmissions to ensure all surviving processes eventually receive each message.

Uploaded by

Sunil Kumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 1

Atomicity

A characteristic of group communication that we have alluded to several times is the


all-or-nothing property. Most group communication systems are designed so that when a
message is sent to a group, it will either arrive correctly at all members of the group, or at
none of them. Situations in which some members receive a message and others do not are
not permitted. The property of all-or-nothing delivery is called atomicity or atomic
broadcast.

Atomicity is desirable because it makes programming distributed systems much easier.


When any process sends a message to the group, it does not have to worry about what to do
if some of them do not get it. For example, in a replicated distributed data base system,
suppose that a process sends a message to all the data base machines to create a new
record in the data base, and later sends a second message to update it. If some of the
members miss the message creating the record, they will not be able to perform the update
and the data base will become inconsistent. Life is just a lot simpler if the system guarantees
that every message is delivered to all the members of the group, or if that is not possible,
that it is not delivered to any, and that failure is reported back to the sender so it can take
appropriate action to recover.

Implementing atomic broadcast is not quite as simple as it looks. The method of Fig. 2-
33 fails because receiver overrun is possible at one or more machines. The only way to be
sure that every destination receives every message is to require them to send back an
acknowledgement upon message receipt. As long as machines never crash, this method will
do.

However, many distributed systems aim at fault tolerance, so for them it is essential
that atomicity also holds even in the presence of machine failures. In this light, all the
methods of Fig. 2-33 are inadequate because some of the initial messages might not arrive
due to receiver overrun, followed by the sender's crashing. Under these circumstances, some
members of the group will have received the message and others will not have, precisely the
situation that is unacceptable. Worse yet, the group members that have not received the
message do not even know they are missing anything, so they cannot ask for a
retransmission. Finally, with the sender now down, even if they did know, there is no one to
provide the message.

Nevertheless, there is hope. Here is a simple algorithm that demonstrates that atomic
broadcast is at least possible. The sender starts out by sending a message to all members of
the group. Timers are set and retransmissions sent where necessary. When a process
receives a message, if it has not yet seen this particular message, it, too, sends the message
to all members of the group (again with timers and retransmissions if necessary). If it has
already seen the message, this step is not necessary and the message is discarded. No
matter how many machines crash or how many packets are lost, eventually all the surviving
processes will get the message. Later we will describe more efficient algorithms for ensuring
atomicity.

You might also like