atomicity in IPC Jonathan S. Shapiro (shap@eros.cis.upenn.edu)
Thu, 12 Mar 1998 17:50:12 -0500

In considering the implications of multiprocessors, I conclude that the atomicity of IPC operations cannot be preserved. I can see no way to efficiently prevent one processor from observing an in-progress IPC made by another.

I am presently unconvinced that preventing this is particularly important. Does anyone care to make a case that it is?

If IPCs are not required to be atomic, then there is a follow-on question: is it acceptable for the content of the recipient's receive data buffer to be undefined between the start and the end of the IPC instruction?

More precisely, assume that the IPC instruction is divided internally into a send phase and a receive phase, the send phase precedes the receive phase, and the receive buffer content is undefined between the start of the receive phase and the end of the receive phase. [This addresses the issue of overlapped send and receive buffers].

If this undefined content state is permitted, then IPC is considerably simplified -- it is no longer necessary to prevalidate the send-side addresses. This allows the data transfer to more closely approximate the performance of ordinary memory copy, and also facilitates the gather implementation (previous note).

At the beginning and end of an IPC, the state of the receive buffer is well defined.

One consequence is that the effects of partially completed IPC operations may be observable by a debugger or by a process on another processor. Consider the following scenario:

Process A initiates an IPC to process B. Midway through the string transfer, A takes a page fault. Third party now examines buffer.
While A is page faulting, process C performs a successful IPC to B.

A second consequence is that the portion of the receive buffer between the receive limit and the actual receive count may have been modified by uncompleted IPCs. The recipient must therefore assume that the entire receive buffer has been overwritten.

I do not think this changes the security arguments. No new channel is created by the presence of data from uncompleted IPC operations.

Does anyone see an objection to this?

shap