Roland Schwarz <roland.schwarz@chello.at> writes:
Anthony Williams wrote:
I posted some MSVC-specific code a short time ago that overcame these problems (see the thread on once init stuff).
I remember those. You said that the solution however is highly compiler/platform dependent, didn't you?
Yes. I wouldn't want to commit to it working with anything other than MSVC. Of course, if someone can verify it with other compilers, that would be good.
So if the mutex ctor cannot be hidden from the public user interface, how should we ever hope to be able to manage this in an compiler independent way? Any ideas?
We could have a separate static mutex, which was POD and relied on zero-initialization, and a dynamic mutex, which wrapped the static mutex with a constructor.
In a private discussion we had, I got the impression, that you were interested in the idea of a POD mutex. Do you still think this is an idea we should pursue?
Yes. I think it is worth pursuing any and all avenues of finding a mutex which can safely be used with either static or dynamic storage duration. In discussions on the C++ Standards committee reflector, it seemed that people were leaning towards an "it just works" interface for std::mutex, which allows it to be declared with any storage duration, without an explicit initializer. This was predicated on the idea that the various library implementers each knew platform- and compiler- specific ways of doing this, so we should specify the most user-friendly interface. Therefore, I think that boost should try and provide this interface as far as we are able. POD mutexes is one way. Named mutexes is another. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk