Discussion :

[Boumbata]

Yop all !


En fait je me pose juste une question concernant les threads (vu que je peux rien tester de mon côté pour le moment je fais appel aux habitués ), en particulier le comportement du lock du mutex:

imaginons N threads appelant une fonction Func, implémentée comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
static boost::mutex my_mutex;
 
void Func()
{
    my_mutex.lock();
    doSomethings();
    my_mutex.unlock();
}

Supposons N1 (premier thread) rentre dans la fonction,lock le mutex et commence à faire ses trucs. Et là se ramène N2 juste après, puis N3 un peu après, etc...

A ce moment, N1 a fini et unlock le mutex. Question: Lequel des threads va locker juste derrière ? N2 ? N3 ? On n'en sait rien ?


Merci beaucoup

[Bousk]

Salut,

il n'y a aucune garantie de l'ordre des threads, au moins sur Windows.
http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

If more than one thread is waiting on a mutex, a waiting thread is selected. Do not assume a first-in, first-out (FIFO) order. External events such as kernel-mode APCs can change the wait order.

[Trademark]

De toutes façons c'est une fausse question, même si c'était en FIFO et que c'était bien défini, à quoi ça pourrait bien servir ? C'est pas comme si tu savais dans quel ordre les threads allaient arriver sur le lock.

[Boumbata]

ok merci c'est bien ce que je pensais mais du coup si l'ordre de passage des threads est important, comment peut-on faire ?

[Ehonn]

On ne fait pas de thread (ou on lance le nouveau thread par celui d'avant) (où on chaîne les std::future).

[Trademark]

Faudrait qu'on en sache plus pour te donner des réponses plus précises car suivant ton problème ton approche peut sûrement être améliorée.

[Boumbata]

ok merci bien pour les infos en fait vu que je me posais juste une question assez générale, je n'ai pas vraiment d'exemple à fournir

Merci bien !