Re: [boost] [interprocess] native Windows cond_var + mutex

Subject: Re: [boost] [interprocess] native Windows cond_var + mutex
From: Dan Brown (dbrown_at_[hidden])
Date: 2011-10-30 16:23:30

> > 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.
> 
> Yes, because in UNIX a process could create a named semaphore / shared
> memory (which is a named resource), increase / write it, exit and then
> another process could get those counts/memory. It's a widely used pattern
> in some environments. In windows, when the creator exits, as it was the only
> attached process, the mutex/memory would be automatically destroyed and
> no new process could get access to it.

So this would be an issue for objects that have initial state that is specified only at creation time not acquisition time, e.g. initial semaphore count.  Can't mutexes be created transparently and atomically?  I think the same would be true of condition variables.  So when the last process exits and destroys the mutex or cond_var, the next process to acquire it creates it.  There can be logical persistence for some objects via their name even if there isn't physical persistence.