Hi Jody, Shmem null mutex was just a fast implementation mainly to avoid mutex overhead with shmem machinery when used with non-shared memory buffers, so I if boost::thread, accepts a null mutex, I would happily use that. I haven't checked your patches, but I would expect a zero overhead mutex, regarding its size (eliminated using empty base optimization) and code generation (lock and unlock are empty functions). Regards, Ion ----- Original Message ----- From: "Jody Hagins" <jody-boost-011304@atdesk.com> To: <boost@lists.boost.org> Sent: Thursday, June 09, 2005 10:03 PM Subject: Re: [boost] Re: [thread] null_mutex
On Thu, 9 Jun 2005 21:41:31 +0200 "Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote:
"Jody Hagins" wrote:
Looking through the archives, a number of requests have been made for a null_mutex, but none exist.
An implementation exists in Shmem library (in Sandbox files).
OK, thanks. A few comments...
Your class is missing: scoped_timed_lock void do_lock(cv_state &); void do_unlock(cv_state &);
which is probably not a big deal if it only used for shmem, and only used with shmem::shared_condition.
However, you would not be able to use this class as a drop-in replacement for any of the other thread::*mutex classes, because it would require reasonable interoperability with boost::condition.