From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2006-11-21 15:54:00
Steve Nutt said: (by the date of Tue, 21 Nov 2006 14:53:22 -0500)
> 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?
How about doing it in a similar way that I already described element
To recall, elemnt handling would be:
- accessor method for reading a sigle element (no writing can occur
when reading, multiple reads are allowed). This means a mutex per
- accessor method for writing an element (no reading can occur when
writing, and only one writing.)
Analogously for whole container:
- iterator is acquiared through accessor method for reading whole
container (container cannot be changed when there is one or more
iterators active - multiple iterators are allowed). This means a mutex
- to modify a container first a lock must be acquiared for writing
(changing) a container. It will be granted only when there are not
active iterators (only one write allowed, no reads allowed)
The container will have to provide it's own (internal) versions of
algorithms, just like PtrContainer does.
In my case adding/removing an element will be rare. So I can live
with locking whole container (and waiting till all iterators release
the lock) for doing that.
-- Janek Kozicki |
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk