-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost- bounces@lists.boost.org] On Behalf Of Ion Gaztañaga Sent: Sunday, October 30, 2011 5:37 AM To: boost@lists.boost.org Subject: Re: [boost] [interprocess] native Windows cond_var + mutex
El 30/10/2011 1:48, Dan Brown escribió:
This was actually my intended point, though maybe I didn't make it clearly. The fact that these libraries (ACE, etc.) provide intraprocess sync objects but not interprocess sync objects is evidence that intraprocess sync objects meet many people's needs. In fact, I find that I need sync objects within a process much more often than I need them between processes.
Interprocess is about cross-process, if you need intra-process Boost.Thread is the natural way. In Interprocess you can customize mutexes used by some classes for intra-process via templates (see http://www.boost.org/libs/dic/html/interprocess/customizing_interprocess. html and class reference for details).
The fact that Boost.Thread provides sync objects is an embarrassing oversight on my part and solves my immediate problem. Thanks for the pointer. Continued curiosity below...
It's a bit long to explain but in windows named resources are reference- counted and are destroyed when the last attached process dies/detaches. Windows has no unnamed process-shared synchronization primitives, unnamed ones are intra-proces only.
In POSIX named resources are file-like (they live until they are explicitly removed) and unnamed can be intra-process or interprocess (PTHREAD_PSHARED). Unnamed interprocess resources must be constructed in shared memory/memory mapped files, use them, unmap them, remap them and continue usihng them. For more details I recommend:
UNIX Network Programming, Volume 2, Second Edition: Interprocess Communications
Thanks for the explanation. The mutex implementation I provided intends to provide "unnamed-like" cross-process mutex semantics by assigning random names. The same can be done with the internal events in interprocess_condition to make them properly interprocess. I realize this presents the corner case of name collision with user-named objects, but this seems unlikely enough not to be a major consideration. Now that I understand the lifetime that applies to (file-like) named objects issue a little better I'm still unsure of why it matters. Why does it matter (other than performance) if on Windows, the object happens to be deleted when the last reference goes away? The "explicit destroy" operation is then a noop on Windows. When it is referenced again it is recreated. There must be some use case that is not occurring to me right now. This is a little bit academic for me now but I remain curious about this case. If a mutex is destroyed in the forest and no one is around to lock it, does it make a sound? ;-)