Hi Shachar,

Have you considered using Unix domain sockets with DGRAM ?
Unix domain sockets as far as I understand, will be reliable even with
DGRAM, which allow you to benefit from the message oriented protocol.

There is only one gotchas here, the enqueuing threads need to make sure
they can queue these messages that cannot be queued if those sockets are
NONBLOCK sockets.

That way no mutexes, no worry about writing/reading only part of the
data.

HTH
Kobi.

On Tue, 2004-07-20 at 14:48, 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"?
> 
> Many thanks,
> 
>                 Shachar
> 
> =================================================================
> 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]
> 
> 

*****************************
Finjan Software

This e-mail and any attached files are confidential and may be legally
privileged. The unauthorized use, disclosure or copying of this email or
any information contained within it is strictly prohibited. This also
confirms that Finjan Software's Vital Security for E-Mail has scanned this
message for the presence of known viruses and potentially malicious
code.

Finjan Software - Prevention is the Best Cure!
*****************************


=================================================================
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