On Tuesday, March 1, 2005, 5:38:54 PM, Darrell wrote: Dsic> I though Pete had some locking mechanism built in to prevent overlapping.
Dsic> Pete....? Yes. This is it. (quite a lot of locking actually) This is a pet peeve of mine so I'm going to go just slightly off topic - it might help someone else out there writing code like this... There are a number of things in Win32 land that are not atomic like they should be. (Atomic meaning - they complete all at once before anything else can happen.) One of these that caused a lot of extra work in SNF peer-server code is rename(). The other is appended writes to a file. As a result, it is possible for more than one thread to believe it has renamed a single file successfully - which is supposed to be impossible. Thread A tries to rename file JOB.QUE to JOB.AAA and succeeds. Thread B tries to rename file JOB.QUE to JOB.BBB and succeeds!!! The actual file name at the end - flip a coin and pick one - JOB.BBB or JOB.AAA. Appended writes work the same way. Thread A opens a file for Append and writes "Thread A stuff and only thread A stuff so there!\n" Thread B opens the same file for Append and writes: "Thread B, thread B, what a silly thread I B!\n" Both writes succeed happily. Unfortunate sleep deprived programmer sure that he is going stark raving mad opens up the file and sees: "Thread A stufead B, what a silly th\n I B! there..." where ... is following on to some other unrelated log entry... (sigh) Luckily, it seems that creating a file is atomic, so there is a way out. This is what I use for some simple inter-process locking (that, by the way, is cross-platform [posix] compatible): open(LockName.c_str(),O_WRONLY|O_CREAT|O_EXCL); --- The actual code I use for locking is bigger than this of course. I'm attaching an excerpt from logger.cpp that takes care of it. Hope this helps, _M
win32lock.cpp
Description: Binary data
