Boost logo

Boost :

From: Steve Nutt (steve.nutt_at_[hidden])
Date: 2006-11-21 14:53:22

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_at_[hidden]]
Sent: Tuesday, November 21, 2006 7:16 AM
To: boost_at_[hidden]
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

> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at