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 access? 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 every element. - 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 per container. - 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 |