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

From: Manuel Jung (gzahl_at_[hidden])
Date: 2007-02-27 02:25:26

Hi,

Yeah thanks for your answer, this is just what i expected. But i also  
thought about a new way with a boost::condition variable to notify (a)  
thread(s), when there is something in the queue.
And because i need those containers in many threads im modeling new  
classes around which are handling all the work on them, all times locked  
with a mutex of course.
Thanks. Thats now clear.
Bye
Manuel Jung

Am 26.02.2007, 23:55 Uhr, schrieb Joaquin M Lopez Munoz <joaquin_at_[hidden]>:

> 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
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

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