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
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
_______________________________________________ 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/