Discussion :

[epeios]

J'essaye de développer ma propre implémentation des mutexes qui soit portable, et donc sans recourir à l'assembleur, ni à une quelconque bibliothèque système (ni standard d'ailleurs). Cette implémentation s'appuye sur la fonction TryToLock() qui essaye de verrouiller un mutex, et retourne true en cas de succés (mutex verrouillé), ou false en cas d'échec (mutex déjà verrouillé, ou en cours de verrouillage par un autre thread). Elle n'est pas bloquante.

Handler est un pointeur sur un octet initialement mis à 0.

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
 
typedef unsigned char *mutex_handler__;
 
int TryToLock( mutex_handler__ Handler )
{
	if ( *Handler != 0 )
		return false;	// Le mutex est déjà verrouillé. On quitte en le signalant.
 
	(*Handler)++;	// Pour signaler que l'on tente de verrouiller le mutex.
 
	if ( *Handler > 1 )
	{
		// Un autre thread est en train d'essayer de verrouiller ce mutex.
		(*Handler)--;	// On se retire de la course.
		return false;	// On signale que l'on n'a pas réussi à verrouiller le mutex.
	} else
		return true;	// On signale que l'on a réussi a verrouiller le mutex.
 
}
 
void Unlock( mutex_handler__ Handler )
{
	(*Handler)--;	// Est remis à 0. Le mutex n'est plus verrouillé.
}	// Cette fonction ne doit être appelée évidemment que sous certaines conditions (mutex verrouillé).

Cette implémentation ne peut fonctionner que si (*Handler)++ (et accessoirement (*Handler)--) est atomique. J'aimerais donc savoir si tel est le cas. Je ne pense pas que quoi que ce soit dans la définition du langage C garantisse cela, mais, pour ce que je connais de l'assembleur et des compilateurs, je pense que cela doit être le cas. Néanmoins, j'espère qu'il se trouvera des personnes sur ce forum dont les connaissances permettront de confirmer ou d'infirmer ce que j'avance.

En outre, un problème peut se poser si plus de 254 threads tentent d'allouer un même mutex. Bien que je n'ai pas jamais eu de logiciels qui lançaient autant de threads de manière concurrente, utiliser un unsigned short voire un unsigned long à la place de l'unsigned char écarterait définitivement ce problème. Mais qu'en est-il alors de l'atomicité de l'incrémentation et de la décrémentation ?

[Médinoc]

Non, ce n'est pas garanti atomique.

Sur des plate-formes spécifiques, on peut s'assurer d'utiliser des instructions assembleur atomiques sur un processeur CISC, mais sur un RISC, y'a peu de chances qu'on trouve cela...

Généralement, les OS proposent des fonctions atomiques pour cela: sous Windows, il y a InterlockedIncrement() et InterlockedDecrement()...

[fearyourself]

Cette implémentation ne peut fonctionner que si (*Handler)++ (et accessoirement (*Handler)--) est atomique.

C'est faux. Puisque (*Handler)++ est divisé en deux parties le chargement de la valeur de pointée par Handler, l'incrémentation puis le stockage de la nouvelle valeur. Il y a 2 endroits (en plus, je fais l'hypothèse que l'exécution d'une instruction assembleur est atomique ce qui n'est pas forcément le cas) où un thread peut s'arrêter en cours de route.

Prenons l'exemple où un thread s'arrête juste avant le stockage.

Code :

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

1
2
3
4
5
6
7
8
9
 
(*Handler) initialisé à 1
Thread1 et Thread2 vont rentrer dans TryToLock
 
Thread1 est en cours d'exécution, passe le premier test, commence l'incrémentation mais s'arrête avant de stocker la nouvelle valeur.
 
Thread2 prend la main, récupère la valeur pointée par Handler: c'est toujours 0!!!
 
Les deux vont donc passer...

[Médinoc]

Généralement, on ne peut pas verrouiller sans une instruction assembleur de type Test-And-Set (les instructions d'incrémentation atomiques, quand il y en a, peuvent parfois être considérées comme en faisant partie).

Ou bien, en désactivant les interruptions.

La plupart des processeurs modernes n'ayant pas d'instruction de manipulation atomique de la mémoire, c'est généralement la seconde méthode qui est utilisée...

[Emmanuel Delahaye]

Mais qu'en est-il alors de l'atomicité de l'incrémentation et de la décrémentation ?

Il faut vérifier dans la norme,

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

mais je pense qu'un opération unaire sur un type sig_atomic_t (signal.h) est insécable.

[epeios]

Merci à tous pour vos indications.

Je n'ai malheureusement rien trouvé de concluant concernant l'atomicité des opérations sur un 'sig_atomic_t' ; dommage, c'eût été portable ...

Je vais m'orienter vers 'Interlocked(In|De)crement' sous Windows (et Cygwin). Sous Linux, l'équivalent semble être 'atomic_(inc|dec)' (disponibles, semble-t'il, dans tous les noyaux de version >= 2.0), ainsi que sous BSD (à première vue).
Il ne me reste plus qu'à trouver l'équivalent pour Mac ...

[gege2061]

Bonjour,

la glib propose un mécanisme de mutex : g_mutex_trylock / g_mutex_unlock. Cette bibliothèque étant relativement portable, le code source pourra peut être d'aider

[epeios]

Un examen sommaire de ces sources révèle qu'ils s'appuyent, me semble-t'il, sur une implémentation des mutexes proposée par d'autres bibliothèques ('pthread' pour Linux, 'Critical Section Objects' pour Windows). Ce que moi je ne veux pas faire, ayant besoin de différents types de mutexes.
Merci quand même ; j'ai découvert l'existence des 'Critical Section Objects' de Windows, même si je n'en n'aurais sans doute jamais l'usage :-) !