Quanto costa l'istruzione lock?

Ho sperimentato il multi threading e l'elaborazione parallela e avevo bisogno di un contatore per eseguire un conteggio di base e un'analisi statistica della velocità dell'elaborazione. Per evitare problemi con l'uso simultaneo della mia classe ho usato un'istruzione lock su una variabile privata nella mia classe:

private object mutex = new object();

public void Count(int amount)
{
 lock(mutex)
 {
  done += amount;
 }
}

Ma mi chiedevo ... quanto costa bloccare una variabile? Quali sono gli effetti negativi sulla performance?

Ecco un articolo che va nel costo. La risposta breve è 50 ns.

La risposta tecnica è che questo è impossibile da quantificare, dipende fortemente dallo stato dei buffer di write-back della memoria della CPU e dalla quantità di dati raccolti dal prefetcher che devono essere scartati e riletti. Che sono entrambi molto non deterministici. Uso 150 cicli della CPU come un'approssimazione all'indietro che evita grosse delusioni.

La risposta pratica è che è mooolto più economico del tempo che impiegherai per eseguire il debug del codice quando pensi di poter saltare un blocco.

Per ottenere un numero difficile dovrai misurare. Visual Studio ha un ottimo analizzatore di concorrenza disponibile come estensione.

Ulteriore lettura:

Vorrei presentare alcuni dei miei articoli, che sono interessati alle primitive di sincronizzazione generali e stanno scavando in Monitor, comportamento dell'istruzione di blocco C #, proprietà e costi a seconda di scenari distinti e numero di thread. È specificamente interessato allo spreco di CPU e ai periodi di throughput per capire quanto lavoro può essere eseguito in più scenari:

https://www.codeproject.com/Articles/1236238/Unified-Concurrency-I-Introduction https://www.codeproject.com/Articles/1237518/Unified-Concurrency-II-benchmarking-methodologies https: // www. codeproject.com/Articles/1242156/Unified-Concurrency-III-cross-benchmarking

Risposta originale:

Oh caro!

Sembra che la risposta corretta contrassegnata qui come LA RISPOSTA sia intrinsecamente errata! Vorrei chiedere all'autore della risposta, rispettosamente, di leggere l'articolo collegato fino alla fine. articolo

L'autore di questo articolo a partire dal 2003 l'articolo stava misurando il unica macchina Dual Core e nel primo caso di misura, ha misurato bloccaggio con un solo filo e il risultato era di circa 50 ns per l'accesso serratura.

Non dice nulla su un blocco nell'ambiente simultaneo. Quindi dobbiamo continuare a leggere l'articolo e nella seconda metà, l'autore stava misurando lo scenario di blocco con due e tre thread, che si avvicina ai livelli di concorrenza dei processori odierni.

Quindi l'autore dice che con due thread su Dual Core, i blocchi costano 120 ns e con 3 thread si arriva a 180 ns. Quindi sembra essere chiaramente dipendente dal numero di thread che accedono al blocco contemporaneamente.

Quindi è semplice, non è 50 ns a meno che non sia un thread singolo, dove il blocco diventa inutile.

Un altro aspetto da considerare è che viene misurato come tempo medio !

Se il tempo delle iterazioni venisse misurato, ci sarebbero anche tempi compresi tra 1 ms e 20 ms, semplicemente perché la maggior parte era veloce, ma pochi thread aspetteranno il tempo dei processori e subiranno ritardi anche millisecondi.

Questa è una cattiva notizia per qualsiasi tipo di applicazione che richiede un throughput elevato e una bassa latenza.

E l'ultimo problema da considerare è che potrebbero esserci operazioni più lente all'interno della serratura e molto spesso è così. Più a lungo viene eseguito il blocco di codice all'interno della serratura, maggiore è la contesa e i ritardi aumentano alle stelle.

Si prega di considerare che è già passato più di un decennio dal 2003, ovvero poche generazioni di processori progettati specificamente per funzionare completamente contemporaneamente e il blocco sta danneggiando considerevolmente le loro prestazioni.

Questo non risponde alla tua domanda sulle prestazioni, ma posso dire che .NET Framework offre un Interlocked.Addmetodo che ti consentirà di aggiungerlo amountal tuo donemembro senza bloccare manualmente un altro oggetto.

lock (Monitor.Enter / Exit) è molto economico, più economico di alternative come Waithandle o Mutex.

Ma se fosse (un po ') lento, preferiresti avere un programma veloce con risultati errati?

Il costo per una serratura in un anello stretto, rispetto a un'alternativa senza serratura, è enorme. Puoi permetterti di eseguire il loop molte volte ed essere ancora più efficiente di un lucchetto. Ecco perché le code senza blocco sono così efficienti.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace LockPerformanceConsoleApplication
{
    class Program
    {
        static void Main(string[] args)
        {
            var stopwatch = new Stopwatch();
            const int LoopCount = (int) (100 * 1e6);
            int counter = 0;

            for (int repetition = 0; repetition < 5; repetition++)
            {
                stopwatch.Reset();
                stopwatch.Start();
                for (int i = 0; i < LoopCount; i++)
                    lock (stopwatch)
                        counter = i;
                stopwatch.Stop();
                Console.WriteLine("With lock: {0}", stopwatch.ElapsedMilliseconds);

                stopwatch.Reset();
                stopwatch.Start();
                for (int i = 0; i < LoopCount; i++)
                    counter = i;
                stopwatch.Stop();
                Console.WriteLine("Without lock: {0}", stopwatch.ElapsedMilliseconds);
            }

            Console.ReadKey();
        }
    }
}

Produzione:

With lock: 2013
Without lock: 211
With lock: 2002
Without lock: 210
With lock: 1989
Without lock: 210
With lock: 1987
Without lock: 207
With lock: 1988
Without lock: 208

Esistono diversi modi per definire il "costo". C'è l'effettivo sovraccarico di ottenere e rilasciare il blocco; come scrive Jake, è trascurabile a meno che questa operazione non venga eseguita milioni di volte.

Di più rilevanza è l'effetto che questo ha sul flusso di esecuzione. Questo codice può essere inserito solo da un thread alla volta. Se si dispone di 5 thread che eseguono questa operazione su base regolare, 4 di loro finiranno per attendere il rilascio del blocco e quindi per essere il primo thread programmato per immettere quella parte di codice dopo che il blocco è stato rilasciato. Quindi, il tuo algoritmo soffrirà in modo significativo. Quanto dipende dall'algoritmo e dalla frequenza con cui viene chiamata l'operazione .. Non puoi davvero evitarlo senza introdurre condizioni di gara, ma puoi migliorarlo riducendo al minimo il numero di chiamate al codice bloccato.