Ubuntu-fr

Plokta

[Résolu]atomic_add_return

Bonjour,

J'essaye d'utiliser les fonctions atomic() mais je ne trouve pas les includes.
Quelqu'un pourrait me dire dans quel paquet ils sont ?

Merci

Dernière modification par Plokta (Le 10/11/2008, à 09:11)

---

Hervé ADAM
http://www.tvpaint.fr

nicolas.sitbon

Re : [Résolu]atomic_add_return

C'est une fonction du noyau, tu l'as trouvera dans les entêtes du noyau.

Plokta

Re : [Résolu]atomic_add_return

C'est une fonction du noyau, tu l'as trouvera dans les entêtes du noyau.

Hum, bizarre que ces fonctions super utiles pour le multithread ne soientt accessible qu'avec les entêtes du noyau.
Merci Nicolas, je regarde si je les trouve.

Dernière modification par Plokta (Le 06/11/2008, à 15:56)

---

Hervé ADAM
http://www.tvpaint.fr

morphoneo69

Re : [Résolu]atomic_add_return

T'as déjà de quoi faire avec la librairie pthreads! Non ?

Plokta

Re : [Résolu]atomic_add_return

T'as déjà de quoi faire avec la librairie pthreads! Non ?

J'implemente des filtres graphiques qui s'executent en multithread.
Les threads s'appliquent sur une ligne de l'image et vont chercher la position de la ligne suivante.

int cMyFilter::GetLine()
{
   Lock();
   int pos = mPosition++;
   Unlock();
   return pos; 
}

un lock/unlock pour chaque ligne est assez catastrophique au niveau des performances, sur windows il y a la fonction InterlockedIncrement() et sur mac OSAtomicAdd32() qui font bien leur boulot.
Je cherche quelque chose d'équivalent sur Linux.

Dernière modification par Plokta (Le 06/11/2008, à 17:03)

---

Hervé ADAM
http://www.tvpaint.fr

morphoneo69

Re : [Résolu]atomic_add_return

Ah ok
http://www.delafond.org/traducmanfr/man/man9/atomic_add.9.html
#include <asm/atomic.h>

Plokta

Re : [Résolu]atomic_add_return

Ah ok
http://www.delafond.org/traducmanfr/man/man9/atomic_add.9.html
#include <asm/atomic.h>

Merci
J'essaye de prendre un peu d'experience, je redécouvre Linux. En fait, j'avais déjà travaillé dessus il y a 8 ans, mais ça a pas mal évolué depuis et j'ai du mal à retrouver mes marques...
Maintenant que j'ai l'include à mettre il me manque les fichiers, j'ai essayé divers paquets mais je n'ai toujours pas trouvé les bons.

Dernière modification par Plokta (Le 06/11/2008, à 17:23)

---

Hervé ADAM
http://www.tvpaint.fr

morphoneo69

Re : [Résolu]atomic_add_return

Il te manque quels fichiers ?

Tu as installé les headers ?

sudo apt-get install linux-headers-`uname -r`

Dernière modification par morphoneo69 (Le 06/11/2008, à 18:25)

Plokta

Re : [Résolu]atomic_add_return

il me manque "asm/atomic.h"

sudo apt-get install linux-headers-`uname -r`  me donne
linux-headers-2.6.27-7-generic

Voila, je ne les ai toujours pas trouvés, je dois etre un peu bete.

---

Hervé ADAM
http://www.tvpaint.fr

nicolas.sitbon

Re : [Résolu]atomic_add_return

Attention tout de même, ces fonctions du noyau ne sont atomic qu'en mode noyau et pas en user space, pour ce la tu as le type sig_atomic_t du langage C :

7.14 Signal handling <signal.h>
1 The header <signal.h> declares a type and two functions and defines several macros,
  for handling various signals (conditions that may be reported during program execution).
2 The type defined is
         sig_atomic_t
  which is the (possibly volatile-qualified) integer type of an object that can be accessed as
  an atomic entity, even in the presence of asynchronous interrupts.

Plokta

Re : [Résolu]atomic_add_return

Attention tout de même, ces fonctions du noyau ne sont atomic qu'en mode noyau et pas en user space, pour ce la tu as le type sig_atomic_t du langage C :

Je ne sais pas si c'est ce que je cherche, je veux juste incremeter  une variable independement des threads (et des CPU), sans trop de pénalité pour les performances. sig_atomic_t semble n'etre utilisé que pour prevenir d'une interruption.
Je suis surpris que ce ne soit pas évident sur Linux, c'est quand meme un OS qui a une bonne réputation pour la gestion du multi-processeur.

---

Hervé ADAM
http://www.tvpaint.fr

nicolas.sitbon

Re : [Résolu]atomic_add_return

Attention tout de même, ces fonctions du noyau ne sont atomic qu'en mode noyau et pas en user space, pour ce la tu as le type sig_atomic_t du langage C :

sig_atomic_t semble n'etre utilisé que pour prevenir d'une interruption.

Pas seulement, le type garantie l'atomicité, c'est bien ce que tu voulais?

Plokta

Re : [Résolu]atomic_add_return

Pas seulement, le type garantie l'atomicité, c'est bien ce que tu voulais?

Atomicité juste pour l'accès, mais dans mon cas il y a deux accès: lecture suivi d'une incrémentation.

---

Hervé ADAM
http://www.tvpaint.fr

nicolas.sitbon

Re : [Résolu]atomic_add_return

Pas seulement, le type garantie l'atomicité, c'est bien ce que tu voulais?

Atomicité juste pour l'accès, mais dans mon cas il y a deux accès: lecture suivi d'une incrémentation.

C'est le même principe que pour interlockedincrement().

Plokta

Re : [Résolu]atomic_add_return

Merci à tous, j'ai trouvé ce que je voulais ici:
http://forums.devx.com/archive/index.php/t-160558.html

inline long InterlockedExchangeAdd( long* Addend, long Increment )
{
long ret;
__asm__ (
/* lock for SMP systems */
"lock\n\t"
"xaddl %0,(%1)"
:"=r" (ret)
:"r" (Addend), "0" (Increment)
:"memory" );
return ret;
}

inline long InterlockedIncrement( long* Addend )
{
return InterlockedExchangeAdd( Addend, 1 );
}

inline long InterlockedDecrement( long* Addend )
{
return InterlockedExchangeAdd( Addend, -1 );
}

inline long InterlockedCompareExchange(volatile long *dest, long exch, long comp)
{
long old;

__asm__ __volatile__ ("lock; cmpxchgl %2, %0"
: "=m" (*dest), "=a" (old)
: "r" (exch), "m" (*dest), "a" (comp));
return(old);
}

inline long InterlockedExchange(long* volatile Target, long Value)
{
long ReturnValue;

__asm __volatile(
"lock xchgl %2,(%1)"
: "=r" (ReturnValue)
: "r" (Target), "0" (Value)
: "memory");

return ReturnValue;
}

---

Hervé ADAM
http://www.tvpaint.fr

nicolas.sitbon

Re : [Résolu]atomic_add_return

Merci à tous, j'ai trouvé ce que je voulais ici:
http://forums.devx.com/archive/index.php/t-160558.html

inline long InterlockedExchangeAdd( long* Addend, long Increment )
{
long ret;
__asm__ (
/* lock for SMP systems */
"lock\n\t"
"xaddl %0,(%1)"
:"=r" (ret)
:"r" (Addend), "0" (Increment)
:"memory" );
return ret;
}

inline long InterlockedIncrement( long* Addend )
{
return InterlockedExchangeAdd( Addend, 1 );
}

inline long InterlockedDecrement( long* Addend )
{
return InterlockedExchangeAdd( Addend, -1 );
}

inline long InterlockedCompareExchange(volatile long *dest, long exch, long comp)
{
long old;

__asm__ __volatile__ ("lock; cmpxchgl %2, %0"
: "=m" (*dest), "=a" (old)
: "r" (exch), "m" (*dest), "a" (comp));
return(old);
}

inline long InterlockedExchange(long* volatile Target, long Value)
{
long ReturnValue;

__asm __volatile(
"lock xchgl %2,(%1)"
: "=r" (ReturnValue)
: "r" (Target), "0" (Value)
: "memory");

return ReturnValue;
}

Je ne vois pas ce que ça apporte de plus à sig_atomic_t, qui plus est, ce code n'est pas portable. Typiquement, voilà comment faire compliqué quand on peut faire simple.

Link31

Re : [Résolu]atomic_add_return

Pas seulement, le type garantie l'atomicité, c'est bien ce que tu voulais?

Le type "volatile sig_atomic_t" ne garantit l'atomicité des opérations que dans le contexte d'une interruption (signaux) selon le standard.

Je me doute bien que ça doit fonctionner en multithread dans la plupart des cas, mais la norme ne parle explicitement que des interruptions... Est-ce qu'à ton avis c'est viable de remplacer un entier protégé par un mutex par un "volatile sig_atomic_t" ? (ça pourrait me faire gagner en clarté du code et peut-être en vitesse)

nicolas.sitbon

Re : [Résolu]atomic_add_return

Pas seulement, le type garantie l'atomicité, c'est bien ce que tu voulais?

Le type "volatile sig_atomic_t" ne garantit l'atomicité des opérations que dans le contexte d'une interruption (signaux) selon le standard.

en réalité la norme ne dit pas que mais même.

even in the presence of asynchronous interrupts.

Je me doute bien que ça doit fonctionner en multithread dans la plupart des cas, mais la norme ne parle explicitement que des interruptions... Est-ce qu'à ton avis c'est viable de remplacer un entier protégé par un mutex par un "volatile sig_atomic_t" ? (ça pourrait me faire gagner en clarté du code et peut-être en vitesse)

La question est plus que pertinente dans la mesure ou langage C n'a pas la notion de thread, néanmoins on peut appliqué l'analogie suivante, toutes fonctions réentrantes est par définition thread-safe (l'inverse n'étant pas vrai bien évidemment), donc oui l'atomicité est garantie aussi dans un thread.

Pour s'en assurer, on peut quand même le vérifier dans la norme, POSIX cette fois -ci (je ne cite que les parties importantes pour nous):

DESCRIPTION
sig_atomic_t
    Possibly volatile-qualified integer type of an object that can be accessed as an atomic entity, even in the presence of asynchronous interrupts.
...
Issue 5

    The DESCRIPTION is updated for alignment with the POSIX Realtime Extension and the POSIX Threads Extension.

.
J'espère avoir été assez clair pour tout le monde.
Cordialement.

Plokta

Re : [Résolu]atomic_add_return

Je ne vois pas ce que ça apporte de plus à sig_atomic_t, qui plus est, ce code n'est pas portable. Typiquement, voilà comment faire compliqué quand on peut faire simple.

sig_atomic_t ne garantit l'atomicité que pour un accès, dans mon cas j'ai besoin de faire une lecture et une incrémentation. ( a = b; b = b+1; )
Je n'ai trouvé nulle part de garantie la dessus.
Pour la portabilité, je laisse les locks/unlocks dans les fonctions génériques et j'utilise l'asm pour les cpu x86.
C'est le prix à payer pour l'optimisation multiprocesseur de mes fonctions, et je vous garantie que l'acceleration des performances vaut le coups. ( Je double pratiquement la vitesse de calcul sur un core duo ).

Dernière modification par Plokta (Le 10/11/2008, à 19:19)

---

Hervé ADAM
http://www.tvpaint.fr

nicolas.sitbon

Re : [Résolu]atomic_add_return

Je n'ai trouvé nulle part de garantie la dessus.

Effectivement mais tu auras le même problème avec InterlockedIncrement sous Windows.

Plokta

Re : [Résolu]atomic_add_return

Effectivement mais tu auras le même problème avec InterlockedIncrement sous Windows.

C'est bien garanti sous windows et sur Mac OSX, je confirme que ça fonctionne.

---

Hervé ADAM
http://www.tvpaint.fr

nicolas.sitbon

Re : [Résolu]atomic_add_return

Effectivement mais tu auras le même problème avec InterlockedIncrement sous Windows.

C'est bien garanti sous windows et sur Mac OSX, je confirme que ça fonctionne.

Non l'atomicité n'est garantie aussi que pour un accès sur ces plateformes, du moins, avec les fonctions cités.

nicolas.sitbon

Re : [Résolu]atomic_add_return

Si tu garantis l'utilisation du compilateur GCC, tu peux utiliser une de ses extensions:
http://gcc.gnu.org/onlinedocs/gcc-4.3.2 … c-Builtins.

Plokta

Re : [Résolu]atomic_add_return

Ca marche et c'est beaucoup plus élégant que les lignes d'assembleur.
Merci Nicolas.

---

Hervé ADAM
http://www.tvpaint.fr

nicolas.sitbon

Re : [Résolu]atomic_add_return

You're welcome