Re: [Boost-users] [IPC Named Mutex]

Subject: Re: [Boost-users] [IPC Named Mutex]
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2015-05-28 15:41:53

El 28/05/2015 a las 21:02, Michael escribió:
> On May 28, 2015 2:50:48 PM EDT, "Ion Gaztañaga" <igaztanaga_at_[hidden]> wrote:
>> El 28/05/2015 a las 12:13, Niall Douglas escribió:
>>> On 27 May 2015 at 18:00, Ion Gaztañaga wrote:
>>>
>>>>> Given that the failure was somewhere related to directory names,
>> what's
>>>>> probably happening is that it's trying to find the name of its
>> shared
>>>>> directory.  For that it evidently wants to use the boot time, as
>> it's a
>>>>> value that should be identical for all processes started since the
>> last
>>>>> reboot, but different between reboots (to avoid getting stale
>> data).
>>>>
>>>> Yes, that's the idea. Obtaining this "unique" identifier between
>> reboots
>>>> that remains stable between all processes it's been incredibly
>>>> difficult. Any alternative or suggestion is welcome.
>>>
>>> On Windows you can mark a filing system entry as always deleted on
>>> close. Such an entry will be deleted on close no matter what,
>>> including power loss and filesystem corruption (the chkdsk with
>>> delete such still existing items).
>>>
>>> If you therefore need a synchronisation object to exist only for this
>>> boot cycle and to always disappear in the next boot cycle, delete on
>>> close is an excellent way of doing it. Why the Windows Temp files
>>> don't default to delete on close is beyond me (you can also unset
>>> delete on close at any time on an open file handle).
>>
>> Can you elaborate, please? What's a "filling system entry"?
>>
>> Delete-on-close would delete the resource when the last attached
>> process
>> exits, so it would be deleted before system reboot a new processes
>> could
>> not connect to the resource. Or am I missing something?
>
> Wouldn't it be a moot point when all mutex consumers closed? Next one fires up and requests a brand new round of shared mutex.

That could work with a mutex, half-work with a semaphore (the count 
should remain stable after the last process closes the handle) and 
broken for a shared memory object.

The key is how to find a unique identifier that identifies each reboot. 
I've tried:

-> kernel boot time. It changes when clock is adjusted
-> WMI LastBootUpTime. A lot of problems with my poor implementation and 
problems after hibernation and clock changes.
-> Look for event ID == 6005 (event log started) in the System event 
log: problems when too many events are appended to the log as that event 
is lost.

Any ideas?

Best,

Ion