Est-ce que ce fil de file d'attente de la file d'attente sans verrouillage?

Étant donné que je ne trouve aucune référence que le verrouillage.exchange lit ou écrit des blocs, je dirais que non. Je voudrais également poser des questions sur la raison pour laquelle vous voulez aller sans verroiement, car il donne rarement suffisamment d'avantages pour contrer sa complexité.

Microsoft a eu une excellente présentation au GDC 2009 à ce sujet et vous pouvez obtenir les diapositives ICI .

Premièrement, je m'interroge sur l'hypothèse de ces deux lignes de code séquentiel: xxx pré>

Que dire que la nouvelle valeur de nœud.data [] a été engagée dans cet emplacement mémoire ? Il n'est pas stocké dans une adresse mémoire volatile et peut donc être mis en cache si je le comprends correctement? Cela ne conduira-t-il pas à une lecture «sale»? Il peut y avoir d'autres endroits la même chose est vrai, mais celui-ci se disait en un coup d'œil. P>

second, code multi-threadé contenant les éléments suivants: p> xxx pré> P> ... n'est jamais un bon signe. Si nécessaire, le code est destiné à échouer, si ce n'est pas nécessaire, c'est un gaspillage. Je souhaite vraiment qu'ils suppriment entièrement cette API. Réalisez que c'est une demande d'attente au moins cette quantité de temps. Avec les frais généraux du contexte basculant, vous allez presque certainement attendre plus longtemps, beaucoup plus longtemps. P>

Troisième, je ne comprends pas complètement l'utilisation de l'API de verrouillage ici. Peut-être que je suis fatigué et je manque juste le point; Mais je ne trouve pas le conflit de fil potentiel sur les deux threads lisant et écrire à la même variable? Il semblerait que la seule utilisation que je puisse trouver pour échanger les échanges de verrouillage serait de modifier le contenu de nœud.data [] à réparer le n ° 1 ci-dessus. P>

Enfin, il semblerait que la mise en œuvre soit quelque peu trop compliquée . Est-ce que je manque le point de tout le curseur / la chose du nœud ou est-ce essentiellement la même chose que cette classe? (Remarque: je ne l'ai pas essayé et je ne pense pas que ceci est le fil en sécurité non plus, essayez simplement de réduire ce que vous pensez.) P>

class ReaderWriterQueue<T>
{
    readonly AutoResetEvent _readComplete;
    readonly T[] _buffer;
    readonly int _maxBuffer;
    int _readerPos, _writerPos;

    public ReaderWriterQueue(int maxBuffer)
    {
        _readComplete = new AutoResetEvent(true);
        _maxBuffer = maxBuffer;
        _buffer = new T[_maxBuffer];
        _readerPos = _writerPos = 0;
    }

    public int Next(int current) { return ++current == _maxBuffer ? 0 : current; }

    public bool Read(ref T item)
    {
        if (_readerPos != _writerPos)
        {
            item = _buffer[_readerPos];
            _readerPos = Next(_readerPos);
            return true;
        }
        else
            return false;
    }

    public void Write(T item)
    {
        int next = Next(_writerPos);

        while (next == _readerPos)
            _readComplete.WaitOne();

        _buffer[next] = item;
        _writerPos = next;
    }
}

Les échecs de recherche Microsoft doivent s'avérer être un bon outil pour tester votre mise en œuvre.

Méfiez-vous du modèle de verrouillage double vérifié (comme dans un lien indiqué ci-dessus: http://www.yoda.arachsys.com/cshaarp/singleton.html )

citant Verbatim de la "conception moderne C ++" de Andrei Alexandrescu

Les programmeurs multithreadés très expérimentés savent que même le motif de verrouillage à double vérification, bien que correct sur papier, ne soit pas toujours correct dans la pratique. Dans certains environnements multiprocesseurs symétriques (ceux qui présentent le modèle de mémoire dite relaxé), les écritures sont engagées dans la mémoire principale des rafales, plutôt que d'une par une. Les rafales se produisent dans l'ordre croissant d'adresses, pas dans l'ordre chronologique. En raison de cette réaménagement des écritures, la mémoire vue par un processeur à la fois peut sembler si les opérations ne sont pas effectuées dans le bon ordre par un autre processeur. Concrètement, l'affectation à PinStance_ effectuée par un processeur peut survenir avant que l'objet Singleton ait été complètement initialisé! Ainsi, malheureusement, le motif de verrouillage à double vérification est connu pour être défectueux pour de tels systèmes