Re: [Boost-users] [multi_index] automatic updating [was: SIGABRT in multi_index_container constructor]

From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2007-02-26 17:55:44

Manuel Jung <gzahl <at> arcor.de> 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