Re: [boost] [ptr_container] and [multi_index] and [thread] -capable containers ?

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