Question about STL containers in multithreaded environment

[nicolas.michel.lava]

Hi there,

I have some trouble using STL containers.
I'm working on a multithreaded (pthread) application making heavy usage
of STL containers. All accesses to containers are made in locked
sections (using mutexes). But sometimes it happens that the application
crashes on container operations. The 2 last crashes are :
* calling push_back on a stl::list object (the backtrace show the last
call was in stl::list::insert);
* accessing an iterator in a list.

I'm absolutely sure that accesses (read and write) are made in locked
sections. That is to say, I'm sure that only one thread is working on a
container at each moment. I can not figure out what's is happening. Is
it possible that allocations failed ? How can iterators be messed up ?
Can anyone give me a hint on what's happening ? Maybe have I
misunderstood something about usage of containers in multithreaded
environment ...

Any help is welcome

Many thanks

Nicolas -

 

[dkotlyarov]

Hi there,

I have some trouble using STL containers.
I'm working on a multithreaded (pthread) application making heavy usage
of STL containers. All accesses to containers are made in locked
sections (using mutexes). But sometimes it happens that the application
crashes on container operations. The 2 last crashes are :
* calling push_back on a stl::list object (the backtrace show the last
call was in stl::list::insert);
* accessing an iterator in a list.

I'm absolutely sure that accesses (read and write) are made in locked
sections. That is to say, I'm sure that only one thread is working on a
container at each moment. I can not figure out what's is happening. Is
it possible that allocations failed ? How can iterators be messed up ?
Can anyone give me a hint on what's happening ? Maybe have I
misunderstood something about usage of containers in multithreaded
environment ...

Any help is welcome

Many thanks

Nicolas -

Maybe some operations with list in one thread invalidate another
thread's iterators, so you get error while trying to access (insert
element) through these iterators.

 

[TB]

(e-mail address removed) skrev:

Hi there,

I have some trouble using STL containers.
I'm working on a multithreaded (pthread) application making heavy usage
of STL containers. All accesses to containers are made in locked
sections (using mutexes). But sometimes it happens that the application
crashes on container operations. The 2 last crashes are :
* calling push_back on a stl::list object (the backtrace show the last
call was in stl::list::insert);
* accessing an iterator in a list.

I'm absolutely sure that accesses (read and write) are made in locked
sections. That is to say, I'm sure that only one thread is working on a
container at each moment. I can not figure out what's is happening. Is
it possible that allocations failed ? How can iterators be messed up ?
Can anyone give me a hint on what's happening ? Maybe have I
misunderstood something about usage of containers in multithreaded
environment ...

Any help is welcome

Many thanks

Nicolas -

Perhaps you should try to aquire an implementation of the standard
library that is multithread safe.

 

[nicolas.michel.lava]

The idea is good but :
Each container is owned by a instance of a class Class. All accesses to
the container are made by calling APIs of Class. No iterator are stored
outside of Class. The containers are not shared between threads,
neither through direct pointer, nor by by iterator.

 

[Dervish]

It seems that your code invalidates iterator. Inavalidation can be even
not related with multithreading. E.g. function foo stores iterator,
calls bar, bar deletes element on which iterator is pointing, bar
returns, foo tries to use stored iterator - crash.

 

[nicolas.michel.lava]

All operations made on iterator are local, and done in "leaf" function
call. There is no risk of iterator beeing invalidated.
What is strange is the crash when calling list:ush_back(). I'm sure
that no other thread was using the container ! To be sure, I look at
the backtrace, and all threads were sleeping.
I'm really lost ...

 

[Jim Langston]

All operations made on iterator are local, and done in "leaf" function
call. There is no risk of iterator beeing invalidated.
What is strange is the crash when calling list:ush_back(). I'm sure
that no other thread was using the container ! To be sure, I look at
the backtrace, and all threads were sleeping.
I'm really lost ...

containers and multi-threading can be a pain. I know I had all kinds of
trouble when I was working on making a thread safe queue class. Perhaps the
compiler is optimizing the code and not rechecking the size of the container
when it should for a push_back.

If you ask in comp.programming.threads I'm sure they'll have lots of ideas
as to what can be going wrong.

 

[Mathias Waack]

Hi there,

I have some trouble using STL containers.
I'm working on a multithreaded (pthread) application making heavy usage
of STL containers. All accesses to containers are made in locked
sections (using mutexes). But sometimes it happens that the application
crashes on container operations. The 2 last crashes are :
* calling push_back on a stl::list object (the backtrace show the last
call was in stl::list::insert);
* accessing an iterator in a list.

I'm absolutely sure that accesses (read and write) are made in locked
sections. That is to say, I'm sure that only one thread is working on a
container at each moment. I can not figure out what's is happening. Is
it possible that allocations failed ?
Yes.

How can iterators be messed up ?
Can anyone give me a hint on what's happening ? Maybe have I
misunderstood something about usage of containers in multithreaded
environment ...

How shall somebody help you without seeing any code...

Mathias

 

[nicolas.michel.lava]

I will post my question on comp.programming.threads news group.
Many thanks.

 

[Pete Becker]

I will post my question on comp.programming.threads news group.

Well, maybe. But the problem might not have anything to do with threads.
Maybe you just screwed up in the use of the container, and the same
problem would occur in a single-threaded version of the code.