cdtyjvПро кривизну с long, который нельзя объявить volatile, мы уже говорили.
зачем тебе это? "Если вам это требуется - значит вы уже свернули не туда, значит у вас уже кривой дизайн."
cdtyjv1) Всем нормальным людям давным давно известно, что нельзя делать апгрейд с read lock до write lock. Это антипаттерн. Если вам это требуется - значит вы уже свернули не туда, значит у вас уже кривой дизайн. Поэтому в Java, например апгрейд делать нельзя - мы, джависты, не любим, кривоту. А что думают по этому поводу разработчики .Net? А им срать, они берут, и имплементируют апгрейд, и имплементируют его криво - что бы получить write lock все равно надо отпустить read lock. То есть это голимейший синтаксический сахар, который только усложняет код. Гомно.
Смотрим на upgradeable lock -
http://msdn.microsoft.com/ru-ru/library/system.threading.readerwriterlockslim.enterupgradeablereadlock(v=vs.110).aspx
Упс, не надо ничего опускать...
cdtyjv2) Ну ладно, подглядели майкрософтовцы в AbstractQueuedSynchronizer в Java, и попытались заимплементировать новый rwlock, который пытается не лезть в операционку, и назвали его ReadWriteLockSlim. Но и здесь их не оставила идея фикс про апгрейд. И они ввели трейтий вид лока - upgradable read lock, который вроде бы уже и не read lock, ибо только один тред может его держать, но еще и не write lock. Но и он опять не решает классическую проблему апгрейда. Ведь если в read lock, то для получения upgradable lock вам надо сначала отпустить read lock. А если вы сразу берете upgradable lock, то другие потоки не смогут его взять. Как обычно - криво, через жопу, проблему не решили, но в API ввели. Гомно.
Нет сценария reald lock -> upgradeable lock -> write lock и нет сценария read lock -> write lock. "Если вам это требуется - значит вы уже свернули не туда, значит у вас уже кривой дизайн." Это в Java есть сценарий read lock -> write lock, ибо нет upgradeable lock. И кроме как "через жопу" такой сценарий сделать нельзя, а в .NET можно.
cdtyjv3) А что, если, например, мне достался legacy код, в котором используется ReadWriteLock, и я захотел его подтянуть под новые омдные тренды, и заменить его ReadWriteLockSlim? В Java Lock и ReadWriteLock - это интерфейсы, потому что разработчики JVM знают, что такое ООП, и в чем смысл фразы "code to interfaces". А в .Net таких итерфейсов нет, и если вы решили поменять RWLock на RWLockSlim, вам придется руками поменять абсолютно все вызовы этого метода. Ведь заботливые разработчики .Net подумали о нас:
ReaderWriterLock.EnterRead
er Lock()
ReaderWriterLockSlim.EnterReadLock()
В Java RWLock и RWLockSlim реализуют одни и те же сценарии. А в .NET ReaderWriterLock и ReaderWriterLockSlim - разные. В частности из-за наличия Upgradeable lock. Но именно из-за "code to interfaces" в Java вообще вообще существует "классическая проблема апгрейда", а в .NET её решили уже 8 лет назад.
cdtyjvИ вы потом рассказываете миру, какой крутой и прогрессивный язык C#? Когда в нем нет ни одного нормального человеческого API? Коллекции - через жопу, но есть LINQ. Многопоточность - через жопу, но есть async/await. Сокеты - просто через жопу, без всяких "но", посмотрите ради интереса на API Java "Selector", и как в JVM нативно реализована операция select, а потом сравните это с убогим и неэффективным Socket.Select() в .Net.
В .NET никто не использует Socket.Select, проще все делать через асинхронный код и async\await.
cdtyjvЯ в ужасе :-(
Это потому что ты паттерны Java пытаешься натянуть на .NET. Но чуваки из МС не дрочат на ООП и "code to interfaces", поэтому уже 10 раз придумали эффективные решения проблем, которые до сих пор в java решают как получится.
Самое смешное:
1) За почти 10 лет в .NET не видел необходимости делать локи вручную, слишком это низкоуровневая вещь. Даже банальный lock(obj) многие лепят там, где он по сути не нужен. Многое уже реализовано в библиотеках, зачастую lock-free.
2) В нынешних условиях тотальной асинхронности в .NET обычные локи уже неактуальны, чаще используют синхронизацию задач через шедулеры и\или очереди.
3) Сокеты вручную довелось писать ровно один раз, потому что сервер был нативный и никаких стандартных протоколов не поддерживал. Для всего остального уже дофига всего напридумано - веб-сервисы, .net.tcp, webapi, signalr. Поэтому если требуется вызывать Socket.Select, то "Если вам это требуется - значит вы уже свернули не туда, значит у вас уже кривой дизайн."
