Opérations atomiques dans ARM

L'idée derrière la charge liée/store-exclusif de paradigme, c'est que si si le magasin suit très bientôt après la charge, sans période d'opérations de mémoire, et si rien d'autre n'a touché l'emplacement, le magasin est probablement pour réussir, mais si quelque chose d'autre a touché l'emplacement du magasin est certains à l'échec. Il n'y a aucune garantie que les magasins ne seront pas parfois tomber en panne sans raison apparente; si le temps entre la charge et le magasin est maintenu à un minimum, cependant, et il n'y a pas d'accès mémoire entre eux, une boucle comme:

do
{
  new_value = __LDREXW(dest) + 1;
} while (__STREXW(new_value, dest));

peuvent généralement être invoqué pour réussir dans un délai de quelques tentatives. Si le calcul de la nouvelle valeur basée sur l'ancienne valeur de certaines de calcul importante, il faut réécrire la boucle tant que:

do
{
  old_value = *dest;

  new_value = complicated_function(old_value);
} while (CompareAndStore(dest, new_value, old_value) != 0);

... Assuming CompareAndStore is something like:

uint32_t CompareAndStore(uint32_t *dest, uint32_t new_value, uint_32 old_value)
{
  do
  {
    if (__LDREXW(dest) != old_value) return 1; //Failure
  } while(__STREXW(new_value, dest);
  return 0;
}

Ce code va être relancé sa boucle principale en cas de modifications *dest, tandis que la nouvelle valeur est calculée, mais seulement la petite boucle devra être recommencée si l' __STREXW échoue pour une autre raison [qui, je l'espère pas trop probable, étant donné qu'il n'y aura qu'environ deux instructions entre l' __LDREXW et __ _ _ STREXW]

Addendum
Un exemple d'une situation où "calculer la nouvelle valeur basée sur l'ancien" pourrait être compliqué serait celui où les "valeurs" sont des références à une structure de données complexe. Le Code peut récupérer l'ancienne référence, et d'en tirer une nouvelle structure de données à partir de l'ancien, puis mise à jour de la référence. Ce modèle arrive beaucoup plus souvent au garbage collector de cadres que dans les "bare metal" de la programmation, mais il existe une variété de façons, il peut arriver, même lors de la programmation de métal nu. Normal malloc/calloc allocateurs ne sont généralement pas thread-safe/interruption sûr, mais allocateurs pour les structures de taille sont souvent. Si l'on a un "pool" d'une certaine puissance de deux nombre de structures de données (dites 255), on pourrait utiliser quelque chose comme:

#define FOO_POOL_SIZE_SHIFT 8
#define FOO_POOL_SIZE (1 << FOO_POOL_SIZE_SHIFT)
#define FOO_POOL_SIZE_MASK (FOO_POOL_SIZE-1)

void do_update(void)
{
  //The foo_pool_alloc() method should return a slot number in the lower bits and
  //some sort of counter value in the upper bits so that once some particular
  //uint32_t value is returned, that same value will not be returned again unless
  //there are at least (UINT_MAX)/(FOO_POOL_SIZE) intervening allocations (to avoid
  //the possibility that while one task is performing its update, a second task
  //changes the thing to a new one and releases the old one, and a third task gets
  //given the newly-freed item and changes the thing to that, such that from the
  //point of view of the first task, the thing never changed.)

  uint32_t new_thing = foo_pool_alloc();
  uint32_t old_thing;
  do
  {
    //Capture old reference
    old_thing = foo_current_thing;

    //Compute new thing based on old one
    update_thing(&foo_pool[new_thing & FOO_POOL_SIZE_MASK],
      &foo_pool[old_thing & FOO_POOL_SIZE_MASK);
  } while(CompareAndSwap(&foo_current_thing, new_thing, old_thing) != 0);
  foo_pool_free(old_thing);
}

Si il n'y va pas souvent être plusieurs threads/interruptions/quel que soit essayer de mettre à jour la même chose en même temps, cette approche devrait permettre des mises à jour à effectuer en toute sécurité. Si une priorité relations existent entre les choses qui peuvent vous essayez de mettre à jour l'élément de même, la plus grande priorité est la garantie de réussir sur sa première tentative, la priorité suivante la plus élevée on va réussir à toute tentative qui n'est pas préempté par la plus haute priorité, etc. Si l'on était en utilisant le verrouillage, la plus haute priorité de la tâche qui voulait effectuer la mise à jour devrait attendre la faible priorité de mise à jour à la fin; à l'aide de la CompareAndSwap paradigme, de la plus haute priorité de la tâche ne sera pas affectée par le taux le plus faible (mais fera en sorte que la partie inférieure avoir à faire le gaspillage de travail).