Shachar Shemesh wrote:
Hi all,

How atomic are read and write?

Background:
I want a queue implemented between different *threads*. At the moment, there are several threads that need to send data, and only one thread that retrieves the data from the queue. The most obvious answer seemed to be "use a pipe".


Here's the schema I was thinking of. Each client (which sends data on the queue) makes a copy (using "new") of the data, and then sends the pointer's address on the pipe using "write". The server does repeated "read"s of 4 bytes, uses the object, and then releases the memory.

The big question is - do I need to introduce a mutex into this mess? Is there a chance that the 4 byte "write" will not be performed in an atomic manner (i.e. - two "write"s will have their data mingled)?

Part II of the question has to do with more than one server. If there is any chance at all that read will not return all 4 bytes in one call, it's obvious that I can no longer guarantee the data integrity, even if "read" itself is atomic. My question is - how likely is it that such a thing will happen? Is there a chance that a series of four bytes "write" operations on a pipe will be split upon "read"?

File: libc.info, Node: Pipe Atomicity, Prev: FIFO Special Files, Up: Pipes and FIFOs

Atomicity of Pipe I/O
=====================

   Reading or writing pipe data is "atomic" if the size of data written
is not greater than `PIPE_BUF'.  This means that the data transfer
seems to be an instantaneous unit, in that nothing else in the system
can observe a state in which it is partially complete.  Atomic I/O may
not begin right away (it may need to wait for buffer space or for data),
but once it does begin it finishes immediately.

   Reading or writing a larger amount of data may not be atomic; for
example, output data from other processes sharing the descriptor may be
interspersed.  Also, once `PIPE_BUF' characters have been written,
further writes will block until some characters are read.

   *Note Limits for Files::, for information about the `PIPE_BUF'
parameter.

-----

File: libc.info, Node: File Minimums, Next: Pathconf, Prev: Options for Files, Up: System Configuration

Minimum Values for File System Limits
=====================================

   Here are the names for the POSIX minimum upper bounds for some of the
above parameters.  The significance of these values is that you can
safely push to these limits without checking whether the particular
system you are using can go that far.  In most cases GNU systems do not
have these strict limitations.  The actual limit should be requested if
necessary.

[...snip...]

`_POSIX_PIPE_BUF'
     The most restrictive limit permitted by POSIX for the maximum
     number of bytes that can be written atomically to a pipe.  The
     value of this constant is `512'.

[...snip...]

-----

RTBMot (Read The Best Manual out there ;-))
libc.info is probably the best piece of documentation I've ever read.
I learnt most of the Unix concepts from just reading through it.

=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]



Reply via email to