Discussion :

[Satch]

Bonjour,
Mes questions existentielles continuent...

Si on a un truc du genre :

Code :

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

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) ?

[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

[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

[Satch]

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

voici un petit test :

Code :

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

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 ??

[xavlours]

Regarde dans les codes source, j'avais posté un mutex de ce genre.ici

[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 ?

[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é.

[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.

[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

[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.

[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.