[Thread] Priorités face à un bloc synchronisé

Version imprimable

19/01/2006, 08h21
Satch

[Thread] Priorités face à un bloc synchronisé
Bonjour,
Mes questions existentielles continuent...

Si on a un truc du genre :
Code:

1 2 3 synchronized(mutex){ ... }
et que plusieurs threads arrivent au synchronized alors que le lock sur mutex est déja pris. Un fois qu'il sera libéré, est-ce que la priorité des threads qui attendent va jouer pour savoir qui ve prendre le lock, ou bien est-ce qu'on peut considérer le lock comme une pile fifo, a savoir le premier à être arrivé sera le premier a éxécuter le code dans le bloc synchronisé (comme c'est le cas apparemment en .NET) ?
19/01/2006, 08h30
Glob

Hello.
Bonne question.

Intuitivement, je pencherais pour que les threads à plus haute priorité passent devant, avec du "pur hasard" pour départager les threads de priorité équivalente.

Mais je suis persuadé que Gfx va nous sortir le numéro du chapitre, dans les specs de la jvm, qui dit comment une jvm doit gérer ça :mrgreen:
19/01/2006, 09h04
ohnerom

si cela se trouve ca va dépendre de la JVM et/ou de l'OS :)

juste au cas ou, pour faire mumuse avec des tread sous java , l'api Concurent Java est tres puissante. Inclue dans Java5 dispo sous forme de jar pour 1.4 .

http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html

Hé bien non, ton intuition était fausse Glob apparement.

voici un petit test :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 import static java.lang.Thread.*; public class Test implements Runnable { private static Object mutex = new Object(); private int numero; public static void main(String[] args) { Thread[] threads = new Thread[3]; for (int i = 0; i < 3; i++) { threads[i] = new Thread(new Test(i)); } threads[0].setPriority(MAX_PRIORITY); threads[1].setPriority(NORM_PRIORITY); threads[2].setPriority(MIN_PRIORITY); for (Thread thread : threads){ thread.start(); } } public Test(int i) { this.numero = i; } public void run() { while (true) { synchronized (mutex) { System.out.println(numero); try { Thread.sleep(500); } catch (InterruptedException e) { e.printStackTrace(); } } } } }
On pourrait s'attendre à voit sur la sortie plus de 0 que de 1 et plus de 1 que de 2.
Pourtant la sortie indique :
0
1
2
0
1
2
0
1
2
...

Donc apparemment le lock est comme une pile FIFO. Je retrouve le même comportement qu'en .NET.

Maintenant, a savoir si ça dépend de la JVM... A fouiller.

Une question me reste... Comment dans un cas comme ça, faire en sorte qu'un thread avec une plus haute priorité ait plus de chance d'exécuter le bloc synchronisé.
Que rajouter ??

19/01/2006, 09h35
xavlours

Regarde dans les codes source, j'avais posté un mutex de ce genre.ici
19/01/2006, 09h45
Satch

Pas bête.

ça correspond à un design pattern connu, ou c'est un truc de ton cru ?

Edit : ça pose quand même un pb. En utilisant tel quel, les threads de faible priorité n'ont plus aucune chance de passer non ?
19/01/2006, 09h56
xavlours

Ben l'héritage des priorités c'est pas de moi, c'est assez connu.

Après, pour toi, la chose intéressante, c'est la file d'attente ordonnée. Mais si tu synchronises des threads de priorités différentes, tu peux avoir à te pencher sur l'inversion des priorités.

Et oui, c'est assez basique comme mutex. Les faibles priorités passent quand les fortes priorités ont fini. Il y aurait peut etre moyen de coder un Comparator qui tienne compte du temps d'attente, afin que l'ancienneté joue dans l'ordre de la file d'attente, et pas seulement la priorité.
19/01/2006, 10h02
ohnerom

dans la lib Concurency :

Sync
Interface for classes used as exclusion, resource management, and related synchronization aids, supporting methods acquire, attempt(msecs), and release.

Implementations

Semaphore
Default implementation of Semaphores, providing no special ordering guarantees.
WaiterPreferenceSemaphore
Provides protection against barging (infinite overtaking)
FIFOSemaphore
Provides first-in/first-out ordering
PrioritySemaphore
Prefers notifications to higher-priority threads
Mutex
Basic non-reentrant mutual exclusion lock
ReentrantLock
Java-style per-thread mutual exclusion lock
Latch
A condition that is acquirable forever more after the first release
CountDown
A condition that is acquirable forever more after the nth release.

en fouillant, tu vas surement t'approcher de ton besoin , enfin peut etre.
19/01/2006, 10h14
Gfx

D'apres ce que j'ai pu lire dans la spec (chapitre 17) et dans les articles suivants (plus faciles a lire surtout aussi tard :), l'ordre d'execution des threads dans le pool d'attente (qui n'est donc pas forcement une file) d'un bloc synchronized depend de l'implementation.

http://www.artima.com/insidejvm/ed2/threadsynch.html http://www.eecs.berkeley.edu/~jimy/java/rendezvous/

Chapitre 17 : http://java.sun.com/docs/books/jls/third_edition/html/memory.html#56318
19/01/2006, 10h22
Satch

Excellent, tout y est.
Merci.

J'ai pas mal de curiosité sur certain sujets mais sur le net je suis comme dans la rue : impossible de trouver mon chemin, c'est maladif.
19/01/2006, 10h31
Gfx

On te pardonne, c'est interessant de lancer ce genre de discussion sur le forum. Java a beau etre un langage (relativement) simple, il y a beaucoup de subtilites et de details interessants.