|
Home > Archive > Unix Programming > May 2005 > Is file<<"Some string"<<endl is an atomic operation.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Is file<<"Some string"<<endl is an atomic operation.
|
|
| Kashish 2005-05-27, 2:48 am |
| 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?
| |
| ibrayem@gmail.com 2005-05-27, 2:48 am |
| "<<" 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.
| |
| Jens.Toerring@physik.fu-berlin.de 2005-05-27, 7:57 am |
| ibrayem@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
| |
| Kurtis D. Rader 2005-05-28, 2:48 am |
| On 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.
|
|
|
|
|