Каким образом решали проблему синхронизации потоков в C#?

А, синхронизация, говоришь? Ну это ж, блядь, святое дело, если хочешь чтобы твоё приложение не разъехалось по швам как пьяный дед на льду. Слушай сюда, я тебе сейчас по полочкам разложу, как я с этим добром обращаюсь.

1. lock — наш бронежилет обыкновенный Это как дверь в сортир на вечеринке захлопнуть. Пока один там свои дела делает, остальные ждут снаружи, терпят. Используется для простых дел, внутри одного процесса.

private readonly object _syncRoot = new object(); // Вот этот самый чурбачок

lock (_syncRoot)
{
    // Тут твоя святая святых. Только один поток в этот момент.
    _sharedList.Add(item); // Добавил и не обосрался
}

А нахуя он? Да потому что проще и быстрее него нихуя нет для большинства случаев. Главное — бери свой личный объект (_syncRoot), а не херачь lock(this). Иначе придут соседи, тоже захотят в твой сортир, и будет deadlock — все поссать хотят, а дверь не открывается.

2. SemaphoreSlim — турникет в метро Представь: есть узкий проход, и ты говоришь — «окей, больше пяти человек одновременно не пускаю». Идеально, когда нужно ограничить потоки, особенно если они асинхронные и не хочется блокировать всё нахуй.

private readonly SemaphoreSlim _semaphore = new SemaphoreSlim(5); // Пять — и хватит!

await _semaphore.WaitAsync(); // Ждём своей очереди как культурные
try
{
    await AccessLimitedResourceAsync(); // Делаем дела
}
finally
{
    _semaphore.Release(); // Выходим, даём место другим. Обязательно!
}

А нахуя он? Он легче своего старшего брата Semaphore и умеет ждать асинхронно (WaitAsync), не занимая попусту поток. Красота, а не инструмент.

3. ReaderWriterLockSlim — библиотека, блядь Ситуация: куча народа хочет почитать одну книжку (данные), но писатель (тот, кто меняет данные) заходит редко. Так вот, пусть читают все сразу, а когда писатель пришёл — все нахуй вышли, подождали, пока он свои правки внесёт, и снова пошли читать.

private readonly ReaderWriterLockSlim _rwLock = new ReaderWriterLockSlim();

// Читатель зашёл
_rwLock.EnterReadLock();
try
{
    return _cache.Get(key); // Читает себе спокойно, пока другие тоже читают
}
finally
{
    _rwLock.ExitReadLock(); // Закрыл книжку, поставил на полку
}

// Писатель приперся
_rwLock.EnterWriteLock(); // Всё, трындец, читатели — свободны!
try
{
    _cache.Set(key, value); // Переписывает историю
}
finally
{
    _rwLock.ExitWriteLock(); // Вышел, теперь можно снова читать
}

А нахуя он? Когда чтения дохуя, а записи раз в год, он даёт овердохуищный прирост производительности. Не заставляй всех стоять в одной очереди из-за одного писаки.

4. Mutex — межгалактический семафор Это когда нужно договориться не только между потоками в одной программе, а между разными процессами, а то и между компами. Классика — чтобы второй экземпляр твоего приложения не запустился.

bool createdNew;
using var mutex = new Mutex(true, "Global\MyAppMutex", out createdNew);
if (!createdNew)
{
    // Ага, сука, кто-то уже сидит в этом кресле!
    return; // Сворачиваемся и идём нахуй.
}
// Мы первые, работаем спокойно...

А теперь, блядь, главные правила, которые надо выжечь на жопе:

• Освобождай блокировки в finally всегда, даже если тебе кажется, что исключения не будет. Иначе залочишь навек — и приехали.
• Сиди в критической секции как можно меньше. Зашёл, быстро сделал дело, вышел. Не надо там чай пить и с коллегами болтать.
• Вложенные блокировки — это ад. Если без них нихуя, то договаривайся о строгом порядке захвата. Всегда сначала замок А, потом Б. Иначе два потока встанут в позу «ты мне — я тебе» и будут ждать вечность.
• Для асинхронного кода — SemaphoreSlim и всякие ConcurrentBag, ConcurrentDictionary твои лучшие друзья. Они заточены под это дело. Не городи велосипед с lock в асинхронных методах, получишь боль и страдание.

Вот так вот, коротко и без воды. Выбирай инструмент по задаче, а не потому что он первый в гугле всплыл.