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.htm... and class reference for details).
If the boost.interprocess sync usage model cannot be more efficiently implemented on win32, either by finding a way to implement the current model, by relaxing the model's requirements (see my next question below), or by providing strictly intraprocess versions of sync objects, then they're unsuitable for my current purposes.
Which are your requirements? If you plan to build portable synchronization objects for intra-process, I think that for intraprocess the natural library is to propose them for Boost.Thread. If you plan to build inter-process mechanisms, then it should fit Interprocess requirements.
To this point in the discussion, only issue I can see as fundamentally preventing the proposed implementation from working (assuming the addition of named-event fixes I alluded to earlier) is the named-object "lifetime semantics" issue that you mentioned, but I'm not sure I understand it fully. It would be helpful for me if you could you clarify the difference in sync object lifetime semantics that make cross-process named win32 sync objects unsuitable for supporting the boost.interprocess version of pthread sync object semantics.
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 http://www.kohala.com/start/unpv22e/unpv22e.html Best, Ion