Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-09-07 08:13:21

--- In boost_at_y..., dmoore_at_a... wrote:
> --- In boost_at_y..., "William Kempf" <williamkempf_at_h...> wrote:
> > >swprintf(name, L"2AC1A572DB6944B0A65C38C4140AF2F4%X%X",
> > >GetCurrentProcessId(), &flag);
> > >
> > >Shouldn't you just generate a UUID for your unique naming prefix?
> >
> > This would work, but wouldn't be as efficient since the same
> mutex
> > would be used for all calls to call_once... even those from
> seperate
> > programs. Adding the GetCurrentProcessId() reduces the
> to all
> > calls to call_once within the process, while adding the address
> &flag
> > reduces it to just the boost::once_flag instance.
> I wasn't actually suggesting a runtime UUID generation, but rather
> that the constant string could be a UUID generated once at compile
> coding time, guaranteeing uniqueness:
> swprintf(name, L"415C0481-8E15-11D3-8861-00104B2D65E0%X%X",
> I'm not actually suggesting that there is a real probability of a
> collision with your random prefix string, but this code is in a
> Windows implementation, and a UUID seemed more MS-ish. Which is a
> long winded way of saying "no big deal"

What I used *IS* a UUID (generated with GUIDGen). I've only removed
the meaningless dashes to shorten the string. However, the process
ID and flag address are still necessary for performance. Does this
explain everything for you?

> > >4. In semaphore::up(), I hadn't seen the idiom of "!!" before.
> > >
> > > bool ret = !!ReleaseSemaphore(reinterpret_cast<HANDLE>
> > count, &p);
> >
> > It's a fairly common idiom (given the name "bang bang") that I
> expect many
> > (most?) people to be aware of. The cast may be more appropriate,
> it's just
> > a pain to code, and a comment would be even worse yet. I'm not
> sure what
> > others think about this idiom.
> Ok, I'll get back on the turnip truck! Ha.

*chuckles* I hope you didn't read that wrong and take offense. None
was meant.

> The only other thing I thought of on further reflection is that
> HANDLEs become 64 bits in the next couple of years, and just
> them into "int" won't work at that point. Not a truly pressing
> issue, but typdefing those entities where POSIX==int and MS==HANDLE
> might be a great idea on the implementation side of things.

I thought about this. However, _beginthreadex uses an int for this
very thing and I've not read any documentation on how MS is going to
handle this when going 64 bit. I'm holding off on any such decisions
until I see how they do it, since I'd prefer to use the same
mechanism they do.

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at