• [^] # Re: vs POSIX shared memory, read-only

    Posté par . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.


    Meme remarque que pbpg: boucler sur un spinlock fait rarement gagner du CPU par rapport à un appel système bloquant. Et si oui, un changement d'algo devrait être sérieusement envisagé.


    Je crois surtout que tu n'as rien compris aux spinlocks.

    Un spinlock, c'est fait pour protéger une section critique extrêmement courte.

    Quand il n'y a pas de contention (en principe la plupart du temps),
    le spinlock ne boucle pas: un spinlock consiste juste en une
    instruction "test&set" du processeur et une boucle si le test échoue.
    Quand le test n'échoue pas et que le lock peut être pris, il n'y a pas
    de boucle et pas de CPU consommé.

    A ton avis, pourquoi les spinlocks sont autant utilisés dans le noyau
    Linux ?

    Après, comparer un spinlock à un appel système, c'est n'importe
    quoi. Sur Linux / i386, un appel système s'effectue par interruption
    (int 0x80). Tu regarderas le nombre de cycles que prend une
    instruction de ce genre sur un CPU, associé avec ça à la sauvegarde
    du contexte du processus, je te garantis que ton spinlock aura
    terminé bien avant.