Boost logo

Boost Users :

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2006-05-11 15:12:12

----- Mensaje original -----
De: george <george13p_at_[hidden]>
Fecha: Jueves, Mayo 11, 2006 7:27 pm
Asunto: Re: [Boost-users] [multi_index] thread safety

> hello Joaquin

Hello George,

> > You have to lockguard every access to the container; note this
> > also includes, for instance, container traversal with iterators,
> > i.e. iterator displacement. Strictly speaking, iterator dereference
> > should also be lockguarded, although I can say unofficially that
> > unguarded dereference is OK.
> can you explain a litle more?
> as I konw from STL, multiple readers is ok.


> reading and inserting a new object does't invalidate iterators(for
> pointer-based
> conteiners offcourse,list, map etc...)

Correct. This also holds for multi_index_containers.

> a concurrent read and insert in multi_index are not
> (safely)possible? I mean there might be an iterator
> invalidation?

Concurrent reading and writing is not safe, but the issue
has nothing to do with iterator invalidation.

...I think I've got a hunch about what you've got in mind.
When I say that you've got to lockguard iterator displacement,
what I mean is: consider a concurrent write operation and
an iterator increment; this concurrency is not thread
safe and undefined behavior results: a possible outcome is
iterator invalidation, but you could also get an app
crash, a corrupted data structure, an infinite loop
or whatever. Tecnhically speaking, an invalid iterator
is a perfectly legal state for an iterator to be in,
which has nothing to do with undefined behavior resulting
from violating thread safety guarantees.

I'm not sure I made myself clear :) Insist on me if I didn't.

> offcourse there is a chance for a 'dirty-read' but this for the
> domain of the aplication if it is a problem and not for multi_index.

I don't get what you mean here, would you care to elaborate?

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at