Code Comments
Programming Forum and web based access to our favorite programming groups.Is file<<"Some string"<<endl is an atomic operation. where file is an ofstream object. If we output a string in ofstream and we provide endl after that,Can we make sure the whole string will be put in file at a time or the string can appear in parts.String lenfth is no more than 50 chars. I have 2 processes on different solaris boxes (NFS) running in parallel.one process writing lines to the file and other process reading lines from the file. Can we make sure filestream and endl that reading process will never get half entry. Either it will get full entry or no entry. or Do I need to use File Locking?
Post Follow-up to this message"<<" is overloaded operators in other words yes they are outomatic operation. "endl" is one of the manipulators recognized by the above operation it simply put newline character and then flush. In case of two process even on same machine if you want the full string u need to synchronize them or use locks on file.
Post Follow-up to this messageibrayem@gmail.com wrote: > "<<" is overloaded operators in other words yes they are outomatic > operation. > "endl" is one of the manipulators recognized by the above operation it > simply put newline character and then flush. If the handling of this isn't too different from what's happening in C (which I would guess isn't the case) then a newline character won't flush() the output buffer when you're writing to a *file* - it only will flush the output buffer in this case when writing to a terminal. The internal functions can determine if they are wri- ting to a file or a terminal and change behaviour depending on that - writes to files are usually delayed until the buffer becomes full and if you want to make sure that they are flushed you need to flush the buffer explicitely or you have to switch to a different buffering mode (setvbuf() in C, I have no idea how you do it in C++, sorry). > In case of two process even on same machine if you want the full string > u need to synchronize them or use locks on file. While that could to be a good idea it won't take care of flushing the buffers when needed - locking happens on a much lower level than writing to a file with the C++ I/O functions, so they won't flush a buffer just because a lock is released. So unless you do the flushing yourself (or switch to a different buffering mode) locking won't help you in that respect. Regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de \__________________________ http://www.toerring.de
Post Follow-up to this messageOn Thu, 26 May 2005 22:40:46 -0700, Kashish wrote: > Is file<<"Some string"<<endl is an atomic operation. > where file is an ofstream object. > > If we output a string in ofstream and we provide endl after that,Can we > make sure the whole string will be put in file at a time or the string > can appear in parts.String lenfth is no more than 50 chars. > > I have 2 processes on different solaris boxes (NFS) running in > parallel.one process writing lines to the file and other process > reading lines from the file. Can we make sure filestream and endl that > reading process will never get half entry. Either it will get full > entry or no entry. or Do I need to use File Locking? Irrespective of any issues involved with buffering and flushing by the C++ iostream mechanism if you are using NFS you have to take special steps to ensure updates are seen by the reader. Do a bit of googling for "nfs" and "cto" or "close to open semantics". Also, even if you implement CTO to deal with cache coherency there are still potential race conditions that could, at least theoretically, cause a "half entry" to be visible by the reader. To solve that you have to use POSIX style locking. That will adversely affect performance but that's that price you'll have to pay if you don't want to use a clustered (i.e., distributed) filesystem.
Post Follow-up to this message
Show a Printable Version
Email This Page to Someone!
Receive updates to this thread
Powered by vBulletin
Copyright 2000-2006 Jelsoft Enterprises Limited.