Andrey Podkolzin podkolzzzin

Публикую на Хабр оригинал статьи, перевод которой размещен в блоге Codingsight.

Я продолжаю создавать текстовую версию своего выступления на митапе по многопоточности. С первой частью можно ознакомиться здесь или здесь, там речь больше шла о базовом наборе инструментов, чтобы запустить поток или Task, способах просмотреть их состояние и некоторых сладких мелочах, вроде PLinq. В этой статье хочу больше остановится на проблемах, которые могут возникнуть в многопоточной среде и некоторых способах их решения.

Содержание

• О разделяемых ресурсах
• Возможные проблемы при работе в многопоточной среде
  • Deadlock
  • Race-Condition
  • Busy-Wait
  • Thread Starvation
• Средства синхронизации
  • Interlocked
  • Monitor.Enter, Monitor.Exit, lock
  • SpinLock, SpinWait
  • Monitor.Wait, Monitor.Pulse[All]
  • ReaderWriterLockSlim
  • Семейство ResetEvent
• Выводы

I have originally posted this article in CodingSight blog

The need to do things in an asynchronous way – that is, dividing big tasks between multiple working units – was present long before the appearance of computers. However, when they did appear, this need became even more obvious. It is now 2019, and I’m writing this article on a laptop powered by an 8-core Intel Core CPU which, in addition to this, is simultaneously working on hundreds of processes, with the number of threads being even larger. Next to me, there lies a slightly outdated smartphone which I bought a couple of years ago – and it also houses an 8-core processor. Specialized web resources contain a wide variety of articles praising this year’s flagship smartphones equipped with 16-core CPUs. For less then $20 per hour, MS Azure can give you access to a 128-core virtual machine with 2 TB RAM. But, unfortunately, you cannot get the most out of this power unless you know how to control interaction between threads.

Публикую на Хабр оригинал статьи, перевод которой размещен в блоге Codingsight.

Необходимость делать что-то асинхронно, не дожидаясь результат здесь и сейчас, или разделять большую работу между несколькими выполняющими ее единицами была и до появления компьютеров. С их появлением такая необходимость стала очень ощутимой. Сейчас, в 2019, набирая эту статью на ноутбуке с 8 ядерным процессором Intel Core, на котором параллельно этому работает не одна сотня процессов, а потоков и того больше. Рядом, лежит уже немного потрепанный, купленный пару лет назад телефон, у него на борту 8 ядерный процессор. На тематических ресурсах полно статей и видео, где их авторы восхищаются флагманскими смартфонами этого года куда ставят 16ти-ядерные процессоры. MS Azure предоставляет менее чем за 20$/час виртуальную машину со 128 ядерным процессором и 2 TB RAM. К сожалению невозможно извлечь максимум и обуздать эту мощь не умея управлять взаимодействием потоков.

Текст этой статьи также доступен на английском.

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

Строго говоря именно это оригинальный текст статьи, а в блоге уже перевод. Здесь статья публикуется чуть позже и только потому получает бирку перевод.

В 2016 году, когда большинство программ выполняются в песочницах, из которых даже самый некомпетентный разработчик не сможет навредить системе, странно сталкиваться с проблемой, о которой дальше пойдет речь. Если честно, я надеялся, что она ушла в далекое прошлое вместе с Win32Api, но недавно я с ней столкнулся. До этого я лишь слышал жуткие байки старых более опытных разработчиков, что такое может быть.

Проблема

Утечка или использование слишком большого числа GDI объектов.

Симптомы:

• В Task Manager на вкладке Details колонка GDI objects показывает угрожающие 10000(Если этой колонки нету, ее можно добавить, кликнув на заголовке таблицы правой кнопкой и выбрав пункт Select Columns)
• При разработке на C# или другом языке выполняемом CLR полетит исключение, не блещущее конкретикой:
  

  Message: A generic error occurred in GDI+.
  Source: System.Drawing
  TargetSite: IntPtr GetHbitmap(System.Drawing.Color)
  Type: System.Runtime.InteropServices.ExternalException

  
  Также при определенных настройках или версии системы исключения может и не быть, но Ваше приложение не сможет нарисовать ни единого объекта.
  
• При разработке на С/С++ все методы GDI вроде Create%SOME_GDI_OBJECT% стали возвращать NULL

На Хабре не слишком много статей, посвященных языку программирования Dart, зато полным полно статей о недоделанных или с трудом доделанных играх, а также о том, как из первых сделать вторые. Данная статья будет смесью этих двух тем.

Дело обстояло так: мы с моим старым другом уже не первый год занимаемся разработкой. Игра, о которой пойдет речь в статье, уже далеко не первая, которую мы пытались сделать, но первая, с которой это удалось. После почти десятка неудавшихся попыток сделать игру мы наконец-то смогли объективно оценить свои силы и решили сделать головоломку. Жанр игр сам по себе несложный, но то, что мы задумали, было куда сложнее и не похоже ни на одну из игр, представленных в каталогах ВК и ФБ в этом жанре. Для того, чтобы совсем не осталось шансов закончить игру, решили использовать те технологии, которые никогда в глаза не видели — Dart + Box2d.