Re: [boost] [thread] A simply static initializeable mutex

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-11-01 05:55:43

Roland Schwarz <roland.schwarz_at_[hidden]> writes:

> Anthony Williams wrote:
>> Roland Schwarz <roland.schwarz_at_[hidden]> writes:
>>> Not sure what this exactly means, can you exemplify?
>
> <examples of simple interface snipped>
>
> Ok, this was nearly obvious to me, I was asking about the "platform
> and compiler specific ways".

e.g. using named mutexes on Windows, using compiler attributes or pragmas to
say "make this thread safe", using my MSVC-specific once-init trick, etc.

> What is wrong or "unsimple" about:
>
> clsss X
> {
>      std::mutex class_data_member;
>
>      X() : class_data_member(0)
>      {}
> }

IMO, the best state of affairs is where there is only one way of initializing
something, which always works. Requiring explicit initialization only under
some circumstances, provides an easy path for making errors.

>>> scoped_lock lk(&foo); should be enough. Implementing this efficiently
>>> however is another story.
>> 
>> No, that's not what I meant. The proposal(s) before the Standards committee
>> are for an explicit mutex type. By "simplest interface" I meant not requiring
>> any explicit initialization under any circumstances.
>
> But scoped_lock lk(&my_foo); does "not require any explicit
> initialization under any circumstances". (With respect to mutex).
> This even beats the class_data_member case. You even can use
> it from inside global ctors.
>
> Btw.: This interface would also be backwards compatible to the
> "explicit mutex lovers": Simply define an pseudo mutex object of
> name mutex. Since it has an address it also will be usable as
> an argument to lock.

Yes. That's why I think it's an important avenue to examine --- if the mutex
address is the only important aspect of the actual object, and all the state
is held elsewhere, such an object can be used without initialization in all
the cases I quoted.

> We were always looking for sync primitives that really are C++ way.
> The most important new thing (with respect to C) is: scoped_lock !
> This really is compelling. So why not take the full step and get
> rid of the "helper class" mutex too? The only really indispensable
> property of a mutex is its ID.

It helps to have an object you can refer to, and call member functions
on. It's also closest to existing practice.

Anthony
-- 
Anthony Williams
Software Developer
Just Software Solutions Ltd
http://www.justsoftwaresolutions.co.uk