Title: | DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) |
Notice: | Welcome to the Digital UNIX Conference |
Moderator: | SMURF::DENHAM |
Created: | Thu Mar 16 1995 |
Last Modified: | Fri Jun 06 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 10068 |
Total number of notes: | 35879 |
I maintain a product which makes use of the undocumented(?) constant PIPE_BUF which indicates minimum guaranteed transfer size without interleaving of data written to a pipe with multiple concurrent writes: my product makes use of this variable by making sure that clients writing to the pipe to the server use data segements of PIPE_BUF bytes or fewer. The product was originally written on single-processor ULTRIX and ported to single-processsor Digital UNIX with no ill effect. On a multi-processor system I occasionally (such as once a week, with several writes occuring in a second) see rubbish data reaching the server i.e. data which is either not what I sent, or possibly interleaved in such a way that it does not make sense to the server: I don't know. Are there any 'gotchas' with using segmented I/O of this form on a multi-processor system? Or could there have been a problem with the port to Digital UNIX that is only showing up now? (Only one writer writes to the pipe simultaneously: this is controlled by a semaphore) +Mark+
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
8892.1 | VAXCPU::michaud | Jeff Michaud - ObjectBroker | Wed Feb 19 1997 11:44 | 15 | |
> I maintain a product which makes use of the undocumented(?) constant PIPE_BUF PIPE_BUF is documented in at least the write(2) man page, if not others. Ie. it's not undocumented. > (Only one writer writes to the pipe simultaneously: this is controlled by > a semaphore) If you are using locking to gain exclusive access to write to the pipe, then PIPE_BUF doesn't matter. I'm assuming you only have one reader at the server side? Why don't you try to reproduce the problem using a small sample program..... | |||||
8892.2 | Is writev atomic? Is semop different on multi-processor machines? | IOSG::MARSHALL | Wed Feb 19 1997 13:03 | 19 | |
It's actually writev that is being used to write to the pipe. The man page states that: The writev() function always writes a complete area before proceeding to the next This suggests that each area may be written by a separate 'write' underneath writev. Is this the case, or is a whole writev call atomic (assuming that PIPE_BUF hasn't been exceeded, of course). Yes, we know this is irrelevant if the semaphores are working correctly, but there's always the possibility they aren't; we just want to eliminate the innocent from this! Is there any difference between using 'semop' on single and dual processor machines? Thanks, Scott (and Mark) |