469,938 Members | 2,473 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,938 developers. It's quick & easy.

using fstream objects in a multiuser environ.


At my current job I've been tasked with maintaining a very old C++
application written largely in ANSI c++ in what I believe to be with an old
DOS based Borland compiler. I'm trying to add a simple event logging
component to the application. Initially I began with a simple:

[...]
fstream dumpfile
dumpfile.open(fname,std::ios_base::out | std::ios_base::app);
[...]
//Event log occurs
dumpfile << dumptext << std::endl;
[...]

But I realized that I would (and did when I started testing) have a problem
because this DOS app is used in a multiuser environment. Competing users
will overwrite eachothers entries if they occur at the same time.
Previously, my pure ANSI c++ experience has been in primarily single
computer/user environs- and any multiuser experience usually got into OS
specific extentions so this never was an issue.

My question is, what methods would someone suggest to me to allow multiuser
access (using any object available in an ANSI environment) which would avoid
such multiuser issues as described above.

Having some experience with race conditions in other os/languages unrelated
to C++, I came up with one idea-- which seemed kludgey. That is to first
check to see if a 'locking' control file exists in a common directory. If
it sees a file there, assume someone else has control of the log file, wait,
repeat step one. If it doesn't find a locking file, create it and write
some unique set of bytes determined by the individual instance (user) of the
app. Wait a 'reasonable' time, then re-read the bytes-- if said bytes
remain as the unique identifier- I can conclude that I have control and can
then open the real log file, write, then delete the 'locking' file when the
write and buffer flush(close) on the log file are complete.

Again, that's the only thing I've come up with. Any advice/criticism (or
especially new ideas) would be appreciated. Thanks in advance,

Paul
Jul 23 '05 #1
4 2130
1) Give each user his own error file with a name like
filename_processid_random_number.txt
2) If you want just one global error file for all users... you can make
sure each user app process logs temporally to memory. Periodically
they could open the global error file with exclusive access flush their
log and close the file

Raj

Jul 23 '05 #2

<ra******@hotmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
1) Give each user his own error file with a name like
filename_processid_random_number.txt
2) If you want just one global error file for all users... you can make
sure each user app process logs temporally to memory. Periodically
they could open the global error file with exclusive access flush their
log and close the file

1: Unfortunately I have a specific application need which disallows a
localized or 'many' log files situation. It must be a centralized log file.

2: But my understanding of ANSI c++ is that there is no exclusive open for a
file. Am I incorrect? Is there an ANSI specification for exclusive access
with an FSTREAM object? Or any other file stream object? I'll research
while I wait for a reply.

Paul
Jul 23 '05 #3

"Pablo" <jn**********@comcast.net> wrote in message news:K8********************@comcast.com...
Having some experience with race conditions in other os/languages unrelated
to C++, I came up with one idea-- which seemed kludgey. That is to first
check to see if a 'locking' control file exists in a common directory. If
it sees a file there, assume someone else has control of the log file, wait,
repeat step one. If it doesn't find a locking file, create it and write
some unique set of bytes determined by the individual instance (user) of the
app. Wait a 'reasonable' time, then re-read the bytes-- if said bytes
remain as the unique identifier- I can conclude that I have control and can
then open the real log file, write, then delete the 'locking' file when the
write and buffer flush(close) on the log file are complete.

Again, that's the only thing I've come up with. Any advice/criticism (or
especially new ideas) would be appreciated. Thanks in advance,


The problem with the lock file is that if one of the users crashes
or has some problems (nic disconnect etc.) the file may not
get cleaned up and you'll be stuck. You probably need some
sort of static instance, maybe a singleton with mutex locks
and a queue mechanism to guarantee that all users work.

Another alternative may be to log to a separate file for
each user and periodically do some sort of merge
into one common file. At least at that point you could
open the files as read only but you still have the problem
that the file may be getting updated while you're merging
it.
Jul 23 '05 #4
I couldn't find one ....

VC++ seems to have a

fstream( const char* szName, int nMode, int nProt = filebuf::openprot
); constructor.

The third argument can used for exclusive access. I am not sure if this
is standard compliant

If you find one, I would be eager to know it as well

Raj

Jul 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by zeroDontSpamMetype | last post: by
9 posts views Thread by boris.smirnov | last post: by
7 posts views Thread by Joe P. Cool | last post: by
4 posts views Thread by Stephen Cattaneo | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.