On Sat, 17 Jul 2004 11:42:18 -0400, Michael Glassford <glassfordm@hotmail.com> wrote:
Matt Hurd wrote: [snip] Actually, all I meant is that I liked the idea of a null mutex (in the context of it being substituted for a real mutex in a single-threaded application).
Kewl. I think that will be a nice small implementation and large conceptual step forward. Another big step forward might be being able to write to a shareable mutex style (rw) and have it work with (by being substitutable for) the other mutex types, policy or not (hopefully with policies). This will make one code base suitable for null_mutex ... shareable_mutex (rw) if you write to the shareable (rw) case. I think we are already largely headed down that line. The main trick here is making shared / exclusive access (r/w) at the lock interface map to just exclusive for the exclusive only mutexes. The other facet is accepting and ignoring the shared / exclusive priorities, e.g. interleaved, exclusive_priority (write priority), etc on mutex construction for the base mutex types. This is a necessarily different approach to having compile time errors for features that are not appropriate. Compile time errors are still appropriate other features, such as timed locks which may not be available due to config/policy. I do have this dream of the types being able to minimally configure themselves based on their use which would be appropriate for some design choices... think of it as a reverse policy approach, but that is research not dev... AFAIK Regards, Matt Hurd.