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 19:35:10

> El 30/10/2011 21:23, Dan Brown escribió:
> > 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.
> 
> No, I can create shared memory write anything into it and unmap it. In
> windows it would be destroyed. In UNIX another process could read
> anything the first process has written.
> 
> I could take a semaphore to count arrived packets increasing the semaphore
> count for each packet, and then exit producer process. After that another
> process could know how many packets arrived. In windows the semaphore
> would be destroyed and the consumer wouldn't get any information.
> 
> The same with a message queue (windows has no native message queue but
> you could do one with shmem and named mutex/condition var). The
> producer can fill the message queue and exit. The consumer takes messages.
> In windows the message queue would be destroyed and data lost.

Agreed.  I was referring to the implementation of mutexes and condition vars.  I believe those could be implemented in the manner I've suggested because they don't have the state issues that you've pointed apply to shared memory and semaphores and other objects.  That is unless there's some interaction of those objects with the other parts of interprocess that I'm not taking into account.