Guys, I know my question is long, but it is actually very simple. It can be summarized as: "Have you used shared_mutex and shared_locks and have you seen an improvement against regular locks?" Thanks, any comments appreciated Alessandro On Aug 25, 2009, at 7:27 AM, Alessandro Bellina wrote:

Hello I am testing the boost mutex/lock classes in order to implement a multiple reader single writer model.

Because of this I thought that the shared mutex with lock_shared and lock_unique would be perfect. I'm finding that the performance is no better than with a simple mutex.

My writer is adding a bunch of elements, locking the shared container exclusivelly until it is done. The readers looks at all elements of the container, locking on a per element basis.

Any ideas as to why the shared mutex would be slower in this case than the simple mutex?

This is the code for my producer thread and my consumers (as a side note, employee_set is a multi index):

typedef boost::shared_mutex mutex_type; typedef boost::shared_lock read_lock_type; typedef boost::unique_lock write_lock_type;

static mutex_type rw_mutex; struct ConsumerThread{ ConsumerThread (employee_set* e):es(e){} void operator()(){ for (int i=0; i<es->size(); i++){ read_lock_type l(rw_mutex); es->get<1>(); } } employee_set* es; };

struct ProducerThread{ ProducerThread(int n, employee_set* e):N(n),es(e){} void operator()(){ write_lock_type l(rw_mutex); for (int i=0; iinsert (employee(i, "TestEmployee",100-i)); } l.unlock(); } int N; employee_set* es; };

Stefan, I think you are right, and also lead to a complete different way of looking at my example. In this application I would want to make sure that I am accessing a multiindex that isn't being changed... so the lock should be outside of the for loop (including the call to size()). I'll look into that example using mutex and shared_mutex. I expect that shared_mutex would be faster, I don't see how it couldn't be. Thanks, Alessandro On Wed, Aug 26, 2009 at 2:51 PM, Stefan Strasser wrote:

I haven't done any performance comparisons, but locking the mutex for each element in the reader thread is not only inefficient but erroneous. you are reading the size of your container outside of any lock, while the writer thread is modifying it. I don't know about the implementation of multi index, if you're lucky size() is an atomic read, but that's certainly not guaranteed by the interface. most std::vector implementations for instance, return (end - begin) as size(), and can cause your reader to crash.

...

Guys, I know my question is long, but it is actually very simple. It can be summarized as: "Have you used shared_mutex and shared_locks and have you seen an improvement against regular locks?"

Thanks, any comments appreciated

Alessandro

On Aug 25, 2009, at 7:27 AM, Alessandro Bellina wrote:

...

Hello I am testing the boost mutex/lock classes in order to implement a multiple reader single writer model.

Because of this I thought that the shared mutex with lock_shared and lock_unique would be perfect. I'm finding that the performance is no better than with a simple mutex.

My writer is adding a bunch of elements, locking the shared container exclusivelly until it is done. The readers looks at all elements of

Am Wednesday 26 August 2009 19:10:23 schrieb Alessandro Bellina: the

...

...

container, locking on a per element basis.

Any ideas as to why the shared mutex would be slower in this case than the simple mutex?

This is the code for my producer thread and my consumers (as a side note, employee_set is a multi index):

typedef boost::shared_mutex mutex_type; typedef boost::shared_lock read_lock_type; typedef boost::unique_lock write_lock_type;

static mutex_type rw_mutex; struct ConsumerThread{ ConsumerThread (employee_set* e):es(e){} void operator()(){ for (int i=0; i<es->size(); i++){ read_lock_type l(rw_mutex); es->get<1>(); } } employee_set* es; };

struct ProducerThread{ ProducerThread(int n, employee_set* e):N(n),es(e){} void operator()(){ write_lock_type l(rw_mutex); for (int i=0; iinsert (employee(i, "TestEmployee",100-i)); } l.unlock(); } int N; employee_set* es; };

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users