As to locking, as I mentioned earlier, I do as little of it as possible: each thread gets its own region for a ring buffer, so the only synchronization required is at thread create time in order to allocate a region from the region map created by the root process/thread the first time it gets into DB::DB. Once thats done, no thread (or process) ever gets in the way of another. A simple thread lock (plus a file lock on *nix systems) covers the allocation step (tho admittedly not well on Win32, but fork() on Win32 is an odd duck anyway which I'm happy to ignore for the present).
The plstrace app doesn't do any locking - it just reads as it needs, checks that the data looks reasonable, and prints it. This isn't a transaction mgr, just a tool to peek at whats going on inside a running app; a little garbage in the stew won't hurt anything.
The most troubling issue is that this is behaving oddly on Win32, an OS that primarily relies on threads (rather than processes) for concurrency, and on memory mapped files for shared memory. So I'd expect things at the system call level to behave a bit more sensibly. Which leads me to believe that the cloning of the mmap'ed tie() may well be doing the damage.
In reply to Re^4: Win32::MMF + threads misbehavior
by renodino
in thread Win32::MMF + threads misbehavior
by renodino
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |