Ok now i get close to solving the problem. My original class is the following: class queue : public queue_set { public: queue(){}; virtual ~queue(){}; void AddQuery(query::pointer Query); void RmQuery(query::pointer Query); void Update(query::pointer Query); boost::mutex m_Queue; typedef boost::shared_ptr<queue> pointer; }; With: void queue::AddQuery(query::pointer Query) { boost::mutex::scoped_lock lm_Queue(m_Queue); insert(Query); } void queue::Update(query::pointer Query) { boost::mutex::scoped_lock lm_Queue(m_Queue); queue_by_id::iterator it=get<tid>().find(Query->id); get<tid>().replace(it,Query); } void queue::RmQuery(query::pointer Query) { boost::mutex::scoped_lock lm_Queue(m_Queue); queue_by_id::iterator it=get<tid>().find(Query->id); get<tid>().erase(it); } If i use it in the example jung.cpp it works. My real world program works without these 4 lines: void AddQuery(query::pointer Query); void RmQuery(query::pointer Query); void Update(query::pointer Query); boost::mutex m_Queue; but not with them enabled! Ok after playing a little bit around with them, i can say the following: Enabling just one of these procedures in my real program -> i get the crash. No function, everything fine. Whats going on here??? These are not called in the constructor!? Up to now they are never ever called! (But i need them of course ;-)) So whats going on, im frightend.. bye Manu

Joaquín Mª López Muñoz wrote:

...

gzahl@arcor.de ha escrito:

...

Hi,

...

Hello Manuel,

...

Hi,

Im defining a class with a multi_index_container as base. When i construct a instance of this class, and the multi_index_container is called, the program crashes. It even crashes, when i dont use it as a base class. [...] This compiles just fine, but if i run the code i get the following backtrace after a Sigmentation Abort. It happens, when the queue::queue() is called. Someone a idee whats it about? Im new to boost::multi_index, so maybe i misunderstud something? Thank you

Well, what you're doing is AFAICS correct, so you shouldn't be getting this crash. You haven't provided a complete test program showing producing the crash, so I wrote one myself after what you've shown and tried it locally, no problems here. Could you please try the attached jung.cpp file? Does it crash also? If it doesn't then there's more to your program than you have described, maybe you can send compilable program showing the issue. If jung.cpp crashes, then could you please provide the following info?

The Testprogramm jung.cpp does not crash on my machines (im testing on a ubuntu 6.10 and a debian 3.1 system, both working with g++ 4.0.2) I will try to get a example which reproduces my error, but in the meantime i was thinking about the libc stuff. Maybe this is the real problem thing? i changed to 4.0.2 from a 3.x version just some weeks ago, so maybe here is the problem, because some lib im using is not compiled with 4.0.2?

It could be. Was everything working OK before switching to 4.0.2? Did you do any significant change to the code after the switch? Can you, just for testing, revert to 3.x and see what happens? Or alternatively, can you do a full build of all the modules invovled? I'm no GCC expert, but if your x in 3.x is less than 4, then there's definitely a C++ ABI change between that and GCC 4.0.2.

I dont know if its a compiler issue, but i didnt used multi_index with another compiler than g++ 4.0.2. Before i was working with the latest 3.x (stable of course). But this was version from here away. So i consider it is no problem of the compiler at first, because i use about 4 or 5 libraries and dont want to recompile them all before trying other things..

...

...

is there a way i can get the compiler version a library was compiled with?

I don't know. Sorry.

[...]

no problem.. still smarter than me *g*

...

...

...

2. The stacktrace mentions a failed assertion in libc.so. Can you see the source code that's causing the assertion? Maybe it sheds some light.

Im not sure about, where to see this sourcecode?

scoped_lock(lightweight_mutex & m): m_(m.m_) { pthread_mutex_lock(&m_); }

these are the lines alst mentioned in the backtrace "/usr/local/include/ boost/detail/lwm_pthreads.hpp:72" from #5. But this is not what you meant, right?

No. The assertion is happening inside libc.so, this is the interesting source code to look at. Again, I'm no GCC expert, but maybe there's some way to link against a debug version of the runtime lib which contains this info (much as your compiled modules have.)

uhh that goes deep in the libstdc++.. :-/ I dont have a clue where to begin with it. i would just stop here and try another way, because i dont think that my code is perfect here.. and i really dont have the time at the moment searching a stdlib bug...

...

Another thing to consider: Have you recently made canges to your code related to the construction of *another* global variables? What I'm thinking of is, if you have some out-of-bounds overwrite somewhere this could be somehow damaging the info inside a neighboring multi_index_container. Just a wild guess...

You could be right here. I have just rewrote the whole managing part of my program. im not sure what could overwrite something, but i think i ahve to reread most of the code now, and test. i have wrote a test program with the whole stucture which seems to matter for the multi_index queue class and it works just fine with no errors. So i have to begin to look of the road..

But its interesting that i can call an instance of queue_set, which works, but no instance of queue. This is kinda weird, isnt it? And i even added in the examples exactly all the stuff i have in the real program and there it still works. (it not very much up to here. just some stuff for gurantee thread safe inserts and a few often used functions.

Greetings Manuel Jung

Ps.: And searching.. and searching...

...

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

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Jeffrey Holle wrote:

...

boost::mutex m_Queue;

but not with them enabled!

Ok after playing a little bit around with them, i can say the following: Enabling just one of these procedures in my real program -> i get the crash. No function, everything fine. Whats going on here??? These are not called in the constructor!? Up to now they are never ever called! (But i need them of course ;-)) So whats going on, im frightend..

Defining a member variable causes either its default constructor or the one you choose to call in the initialization clause to be called in your class's constructor.

So assume that your problem is in the default constructor of boost::mutex.

Hi, That cannot be right. It works with just the definition of the boost::mutex. But i dont works with some of the procedures. So the boost::mutex is not the problem. Greetings Manuel Jung

"JOAQUIN LOPEZ MU?Z" wrote:

----- Mensaje original ----- De: Manuel Jung Fecha: Jueves, Febrero 15, 2007 9:01 pm Asunto: Re: [Boost-users] [multi_index] SIGABRT in multi_index_containerconstructor Para: boost-users@lists.boost.org

...

Ok now i get close to solving the problem.

My original class is the following:

class queue : public queue_set { public: queue(){}; virtual ~queue(){}; void AddQuery(query::pointer Query); void RmQuery(query::pointer Query); void Update(query::pointer Query); boost::mutex m_Queue; typedef boost::shared_ptr<queue> pointer; }; [...] If i use it in the example jung.cpp it works. My real world program works without these 4 lines: void AddQuery(query::pointer Query); void RmQuery(query::pointer Query); void Update(query::pointer Query); boost::mutex m_Queue;

but not with them enabled!

Ok after playing a little bit around with them, i can say the following: Enabling just one of these procedures in my real program -> i get the crash. No function, everything fine. Whats going on here??? These are not called in the constructor!? Up to now they are never ever called! (But i need them of course ;-)) So whats going on, im frightend..

Well, I might be totally wrong, but the more you describe the problem the more it looks to me like some neighboring variable corrupting the space occupied by your queue object. I've got several questions and suggestions to try to test whether this hypothesis is true:

1. The crashing queue object, is it a gobal variable? If so, can you try moving its definition so as to displace it with respect to other global variables in the same translation unit? I mean, if your code looks like:

Its not a global variable, but part of a class. Its a public object created in a shared_ptr.

some_type1 var1; some_type2 var2; queue q; some_type3 var3;

try shuffling it a bit like vg:

queue q; some_type1 var1; some_type2 var2; some_type3 var3;

You get the idea.

2. [assuming the object is global] If there are no neighboring vars, try planting some safe areas around the queue object:

char pre[256]; queue q; char post[256];

3. [assuming the object is global] Try, just for testing purposes, to momentarily comment the offending queue out and declaring a queue object as a stack variable:

int main(){ queue q; ... }

Crash/no crash?

im tired and will try this later. Probably Saturday, cause i can test it tommorow, but dont post it.. im in a train ;-).

4. Last of all, your problem involves an internal mutex object which is only defined when you set Boost.MultiIndex safe mode on (you've got it set on, right?) If you turn this mode off you won't get the crash, but this is IMHO just masking the actual problem, which could appear under a different guise later on.

yes, the safe mode is on with this code: #if !defined(NDEBUG) #define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING #define BOOST_MULTI_INDEX_ENABLE_SAFE_MODE #endif when i switched it off, the error vanished, but even better some libcurl/curlpp related error vanished! I have even some strange error about clearing the Multihandle of curlpp. He says he cannot free a pointer. I dont know if these errors are really related... but probably they are? This error popped up when exiting from the program, but i couldnt test it really, cause i couldnt send a Strg-C when running in gdb... but it seemed to exiting cleanly. So i'll try variable shifting tommorow. Goot night, Manuel Jung

Good luck, please keep me informed,

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

"JOAQUIN LOPEZ MU?Z" wrote:

----- Mensaje original ----- De: Manuel Jung Fecha: Jueves, Febrero 15, 2007 11:17 pm Asunto: Re: [Boost-users] [multi_index] SIGABRT in multi_index_containerconstructor Para: boost-users@lists.boost.org

[...]

...

yes, the safe mode is on with this code: #if !defined(NDEBUG) #define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING #define BOOST_MULTI_INDEX_ENABLE_SAFE_MODE #endif

Hey, I had an overlook! The jung.cpp file I sent you only defines the safe mode macro, but you've got to define both this and the invariant checking macro to reproduce the problematic conditions. Could you please add (at line 1) the missing

#define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING

and check whether you still are crash free? I don't think this overlook will make any difference, but it's better to be on the safe side.

Hi, no difference here. All the same in the test case. It runs just fine. Manuel Jung

Thank you,

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

----- Mensaje original ----- De: Manuel Jung Fecha: Sábado, Febrero 17, 2007 8:07 pm Asunto: Re: [Boost-users] [multi_index] SIGABRT in multi_index_containerconstructor Para: boost-users@lists.boost.org

Hi,

I think something ist bad about the SAFE MODE or INVARIANT CHECKING. With them active, i have some trouble with other variables and containers of my programm. e.g. with a curlpp::Multi and even with a std::list. If i switch these Scripts of everything works fine. when they were switched on, the size() member didnt work for example. I dont know about the library that much but it seems there is some bug in the SAFE MODE scripts. :-(

Greetings Manu

Hello Manu, Unfortunately, your mere statement of the problem doesn't provide me with enough information to try to discern whether there's really an issue with Boost.MultiIndex or if the problem lies somewhere else. I'd need a reproducible test case to work with, and I understand you're not in the position to produce one. Of course there can be a bug in the implementation of safe mode or invariant checking modes --I just can't know from the evidence you presented. I would like to ask you for a last favor: Maybe you could download a snapshot of the future Boost 1.34 release from http://engineering.meta-comm.com/boost/snapshot/boost-RC_1_34_0.tar.bz2 and see what's the outcome with this? There are some safe mode-related bugs fixded in this version, though none of them looks like having to do with your problem at first sight. But if you only could give it a try... Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

Ps.: For now ill use std::queue and try later upgrade to multi_index's for more features and better priority sorting.

...

"JOAQUIN LOPEZ MU?Z" wrote:

...

----- Mensaje original ----- De: Manuel Jung Fecha: Jueves, Febrero 15, 2007 11:17 pm Asunto: Re: [Boost-users] [multi_index] SIGABRT in multi_index_containerconstructor Para: boost-users@lists.boost.org

[...]

...

yes, the safe mode is on with this code: #if !defined(NDEBUG) #define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING #define BOOST_MULTI_INDEX_ENABLE_SAFE_MODE #endif

Hey, I had an overlook! The jung.cpp file I sent you only defines the safe mode macro, but you've got to define both this and the invariant checking macro to reproduce the problematic conditions. Could you please add (at line 1) the missing

#define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING

and check whether you still are crash free? I don't think this overlook will make any difference, but it's better to be on the safe side.

Hi,

no difference here. All the same in the test case. It runs just fine.> Manuel Jung

...

Thank you,

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

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Hi, After a working version with std::queue's im now back to multi_index_container. And new try new idea! I found out something: This "#define" block -------cut-------- #if !defined(NDEBUG) #define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING #define BOOST_MULTI_INDEX_ENABLE_SAFE_MODE #endif -------cut-------- was before all my #include's up to now. And if the "SAFE_MODE" was enabled i was getting SEGFAULTs. But now i dropped this blocked after all my includes in the header file or even in the main implemantation file and dont get the errors anymore! I hope this helps/makes any sense to you? Greetings Manuel Jung

"JOAQUIN LOPEZ MU?Z" wrote:

Hello Manual, thank you for not abandoning this problem!

----- Mensaje original ----- De: Manuel Jung Fecha: Domingo, Febrero 25, 2007 11:43 am Asunto: Re: [Boost-users] [multi_index] SIGABRT in multi_index_container constructor Para: boost-users@lists.boost.org

...

Hi,

After a working version with std::queue's im now back to multi_index_container. And new try new idea! I found out something:

This "#define" block -------cut-------- #if !defined(NDEBUG) #define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING #define BOOST_MULTI_INDEX_ENABLE_SAFE_MODE #endif -------cut-------- was before all my #include's up to now. And if the "SAFE_MODE" was enabled i was getting SEGFAULTs. But now i dropped this blocked after all my includes in the header file or even in the main implemantation file and dont get the errors anymore!

I hope this helps/makes any sense to you?

It does make sense, but it doesn't provide much info: those macros have to be defined before inclusion of B.MI headers to take effect, so that having them after the includes is entirely equivalent to not defining them :(

okay, it has clearly no effect to defines variables/flags, hwich are not used...

Can you (I mean, are you allowed to) provide a sketch of the class where the offending queue class is being used? I remember you said it's a member of a more complex class, or something like that.

Hm, i think i can do that, nobody could use a part of the code anyway (or would like..); But which part of it do you like? The Header? Or a part of the header? Or parts of code where the first error with the scripts are raising? Greetings, Manu Ps.: I have some question about the mem_fun. You cannot have a index which is automaticly recalculated within a member function, can you? Im thinking about a function checking, if a try_mutex is locked. But i think, this is a gainst the natured of a index. Am i right?

Thank you,

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

Hi, Sorry for hte delay, but i was in a train again yesterday, with no internet... But here im back now.

I don't really know :) I'm trying to gain more info on the context where the core happens. Let's begin with say the header and then we will pull from this thread if necessary, OK?

you got two files with this message. These are the slots.h and octopus.h. They are the only ones with multi_index_container definitions. Tell me what you need else. The files are just how they are, nothing is stripped out.

...

Ps.: I have some question about the mem_fun. You cannot have a index which is automaticly recalculated within a member function, can you? Im thinking about a function checking, if a try_mutex is locked. But i think, this is against the natured of a index. Am i right?

I'm not getting your question. Could you please reformulate it using some pseudocode of your intended mode of usage? Thank you!

Ok i'll try: Imagine some Function bool slot::IsIdle() { boost::try_mutex::scoped_try_lock lm_idle(m_idle); return lm_idle.locked(); } The class "slot" models the idea of a slot which does some work in its own thread. It automaticly locks a try_mutex if its doing something. i have a multi_index_container with a couple of these "slot" objects. One of the indexs should take the IsIdle function as key, so i can select just the range of "slot" objects, which are idle and waiting for some work. Im not writing the code for the function (because i dont know how i should do..). My question about this is: I should have to update the multi_index_container (modify/replace) manual, when the IsIdle status changes, right? the container wouldn't serve me with the actual (at the time of doing some "range" query) result of the IsIdle function? So far. Manuel Jung

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

Manuel Jung ha escrito:

you got two files with this message. These are the slots.h and octopus.h. They are the only ones with multi_index_container definitions. Tell me what you need else. The files are just how they are, nothing is stripped out.

Hello Manuel, before I begin studying your post, I think you forgot to attach slots.h. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

Manuel Jung writes:

...

Hi,

Sorry for hte delay, but i was in a train again yesterday, with no internet... But here im back now.

...

I don't really know :) I'm trying to gain more info on the context where the core happens. Let's begin with say the header and then we will pull from this thread if necessary, OK?

you got two files with this message. These are the slots.h and octopus.h. They are the only ones with multi_index_container definitions. Tell me what you need else. The files are just how they are, nothing is stripped out.

Hello, thanks for the files. There's a detail that smells funny: octopus.h begins with

#if !defined(NDEBUG) #define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING #define BOOST_MULTI_INDEX_ENABLE_SAFE_MODE #endif

(which is commented out in the version you've sent, but I guess it is when in effect that the crash happens, right?) Yeah, sure. Just commented out, so i can do my work, without minding my

Am 26.02.2007, 23:32 Uhr, schrieb Joaquin M Lopez Munoz : little problem.

whereas slot.h does not have these macros, unless they're defined in diver.h or in myconnection.h. No, they dont have them.

Could it be that Boost.MultiIndex headers are included by diver.h or myconnection.h or slot.cpp (assuming this is the name where queue::AddQuery etc. are define) *without* defining safe mode and invariant checking macros? Yeah, this is true. The headers where defined in the diver.h, because i was trying and moving code a little bit around at the beginning of using Boost.MultiIndex. I have now fixed it. I dont get an error yet, but a i cannot run a full test, because some of the functions are broken at the moment. Ill fix that this evening and than well see whats up.

If so, you've got a problem: these macros have to be defined/undefined *globally*. i.e. you cannot compile one .cpp with them turned on and other without them: object incompatibility ensues.

Is this in the documentation and i didn realize? Maybe it should be said explicit, if its not in there.

Looking forward to your feedback,

Some more results in about 12 hours. Greetings Manuel Jung

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

PS: I answer your other question at a separate thread.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

Am 27.02.2007, 13:10 Uhr, schrieb Joaquín Mª López Muñoz :

Manuel Jung ha escrito:

...

Am 26.02.2007, 23:32 Uhr, schrieb Joaquin M Lopez Munoz :

...

Manuel Jung writes:

[...]

...

...

#if !defined(NDEBUG) #define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING #define BOOST_MULTI_INDEX_ENABLE_SAFE_MODE #endif

[...]

...

...

If so, you've got a problem: these macros have to be defined/undefined *globally*. i.e. you cannot compile one .cpp with them turned on and other without them: object incompatibility ensues.

Is this in the documentation and i didn realize? Maybe it should be said explicit, if its not in there.

It is stated in the docs, if a tad too laconically, maybe:

"Boost.MultiIndex safe mode is set by globally defining the macro BOOST_MULTI_INDEX_ENABLE_SAFE_MODE."

"The so called invariant-checking mode of Boost.MultiIndex can be set by globally defining the macro BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING."

Yeah, i read this lines before, but didnt realize something that bad could happen if im not defining globally.

in http://www.boost-consulting.com/boost/libs/multi_index/doc/tutorial/debug.ht... . The key word here is "globally". Perhaps I should be more explicit about this issue.

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

Greetings Manuel Jung -- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

Manuel Jung wrote:

Am 26.02.2007, 23:32 Uhr, schrieb Joaquin M Lopez Munoz :

...

Manuel Jung writes:

...

Hi,

Sorry for hte delay, but i was in a train again yesterday, with no internet... But here im back now.

...

I don't really know :) I'm trying to gain more info on the context where the core happens. Let's begin with say the header and then we will pull from this thread if necessary, OK?

you got two files with this message. These are the slots.h and octopus.h. They are the only ones with multi_index_container definitions. Tell me what you need else. The files are just how they are, nothing is stripped out.

Hello, thanks for the files. There's a detail that smells funny: octopus.h begins with

#if !defined(NDEBUG) #define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING #define BOOST_MULTI_INDEX_ENABLE_SAFE_MODE #endif

(which is commented out in the version you've sent, but I guess it is when in effect that the crash happens, right?) Yeah, sure. Just commented out, so i can do my work, without minding my little problem.

...

whereas slot.h does not have these macros, unless they're defined in diver.h or in myconnection.h. No, they dont have them.

...

Could it be that Boost.MultiIndex headers are included by diver.h or myconnection.h or slot.cpp (assuming this is the name where queue::AddQuery etc. are define) *without* defining safe mode and invariant checking macros? Yeah, this is true. The headers where defined in the diver.h, because i was trying and moving code a little bit around at the beginning of using Boost.MultiIndex. I have now fixed it. I dont get an error yet, but a i cannot run a full test, because some of the functions are broken at the moment. Ill fix that this evening and than well see whats up.

...

If so, you've got a problem: these macros have to be defined/undefined *globally*. i.e. you cannot compile one .cpp with them turned on and other without them: object incompatibility ensues.

Is this in the documentation and i didn realize? Maybe it should be said explicit, if its not in there.

...

Looking forward to your feedback,

Some more results in about 12 hours.

Hi, Took somewhat more time than 12 hours, but now im back here and the work is done. And my problem is fixed now. So the problem was that i defined tine INVARIANT and SAFE_MODE scripts not for every Boost.Multi_Index. Ill hope nobody will ran in this again :-o. Thanks very much to you Joaquín. You helped very fast and friendly. Even thanks for your great library. Maybe ill have some question again sometime. Not a very easy to use library at first, because its so nice and is very flexible. But now i think i got the most things i need. Thank you! I would send you some flowers, if you were not that far away (i think?). Best wishes, Manuel Jung

Greetings Manuel Jung

...

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

PS: I answer your other question at a separate thread.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Manuel Jung writes: [...]

...

...

Ps.: I have some question about the mem_fun. You cannot have a index which is automaticly recalculated within a member function, can you? Im thinking about a function checking, if a try_mutex is locked. But i think, this is against the natured of a index. Am i right?

I'm not getting your question. Could you please reformulate it using some pseudocode of your intended mode of usage? Thank you!

Ok i'll try:

Imagine some Function

bool slot::IsIdle() { boost::try_mutex::scoped_try_lock lm_idle(m_idle); return lm_idle.locked(); }

The class "slot" models the idea of a slot which does some work in its own thread. It automaticly locks a try_mutex if its doing something.

i have a multi_index_container with a couple of these "slot" objects. One of the indexs should take the IsIdle function as key, so i can select just the range of "slot" objects, which are idle and waiting for some work. Im not writing the code for the function (because i dont know how i should do..). My question about this is: I should have to update the multi_index_container (modify/replace) manual, when the IsIdle status changes, right? the container wouldn't serve me with the actual (at the time of doingsome "range" query) result of the IsIdle function?

Yep, you have to manually resync the index via modify(), and you have to do it in a thread-safe manner, i.e all access to the multi_index_container (slots in your case, I guess) should be serialized via a mutex (slots::m in your case.) Resyncing would be done like this: // right after becoming idle boost::lock lm(my_slot_container->m); // see http://lists.boost.org/boost-users/2007/02/25632.php // for info about null_modifier my_slot_container->modify(my_iterator,null_modifier()); It is probably easier, more robust and more efficient to maintain an is_idle bool member tracking the idle/busy state, rather than relying directly on IsIdle, in which situation the resyncing code could look like this: void set_idle_state { set_idle_state(bool i):i(i){} void operator()(slot& s)const { s.idle_state=i; } bool i; }; ... boost::lock lm(my_slot_container->m); my_slot_container->modify(my_iterator,set_state(false)); There's a little quirk with this, you've got to somehow be able to associate the appropriate slots container and iterator to each slot. HTH, Joaquín M López Muñoz Telefónica, Investigacióin y Desarrollo