If it were desirable to mix the locking with the container, use a locking policy. This would allow no locking, mutexed locking, and perhaps atomic operations when available. Iterators tend to be a pain. How do you propose the iterator would work when another thread is trying to change the container? -----Original Message----- From: Thorsten Ottosen [mailto:thorsten.ottosen@dezide.com] Sent: Tuesday, November 21, 2006 7:16 AM To: boost@lists.boost.org Subject: Re: [boost] [ptr_container] and [multi_index] and [thread] -capable containers ? Janek Kozicki wrote:
Thorsten Ottosen said: (by the date of Tue, 21 Nov 2006 00:03:21 +0100)
I'm still thinking how to best refactor my current containers. They are in bad need for refactoring and I'm still not sure where to go. MultiIndex + PtrContainer are one of alternatives. If it turns out that this is the way to go, I will want to try this task.
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. -Thorsten