Re: [boost] [thread] - capable containers ?

From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2006-11-21 08:50:15

Thorsten Ottosen said:     (by the date of Tue, 21 Nov 2006 13:16:29 +0100)

> > Also I'm sure that my new container will have to support threading. I
> > was thinking about something like accessor methods that will lock for
> > reading and lock for writing:
> > 
> > template <T>
> > class my_superb_container {
> > 
> > // only one can write to item 'item_index', no reading allowed
> >     T& lock_write(int item_index); 
> > 
> > // multiple reads of item 'item_index' are allowed, no writing
> >     const T& lock_read(int item_index);
> > }
> > 
> > Lock will be released when leaving current block, in the destructor.
> > (destructor of what? - still thinking about that).
> 
> It seems like a bad idea to mix threading into the container itself. 
> Threading should be an orthogonal issue; once you have the container 
> design worked out, threading can be added by your-self on top of that.

In my problem I don't need this container to me <algorithms> -capable.
It is only to store data on which numerous threads will work on.
Rarely adding or removing elements, mostly changing their content,
and reading it.

Therefore I don't want a single mutex for whole container. I want one
thread to be able to write to one element, while other threads can
work with other elements. Single mutex would block whole container
just because one thread is working on a single element.

I see no other option than to have another container of mutexes: one
mutex per element. Is there anything else I can do?

With this solution the threading cannot be orthogonal. Or I'm missing
something?

-- 
Janek Kozicki                                                         |