Atomicité de l'incrémentation d'un entier.
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:
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 ?
Re: Atomicité de l'incrémentation d'un entier.
Citation:
Envoyé par epeios
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.
