Чтобы получить состояние взаимоблокировки нужно использовать вложенные блоки synchronized, если Вам нужно заблокировать несколько mutex'ов их нужно использовать в одном блоке синхронизации. Использование в одном блоке безопасно, так как действительный порядок блокировки не зависит от порядка написания объектов синхронизации и он всегда будет одинаков. То есть, если в одном блоке сначала блокируется A а затем B, то и в других блоках этот порядок сохранится. Начёт передачи сообщений вы заблуждаетесь через CAS, в std.concurrency используются для этого обычная схема с блокировками. И если честно не совсем представляю как можно для этого использовать CAS, было бы не плохо, если бы Вы привели пример.

Всего не знаю, но, мне кажется, что на C++ вообще нет такой безопасности.

на большой выборке Rust всё равно победил)

тов I_AM_FAKE напсал намного раньше чем Вы, просто я смог выложить это только сейчас. И у Вас нет сохранения набора точек в классах.

да, так и должно быть

да, ровно 100000

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

При вызове какого либо метода блокируется весь объект, а не метод, так как у всех методов один обеъкт синхронизации, так что методы могут быть вызваны только последовательно. Он с этой стороны не опасен, а не производителен.

Было бы очень классно. Выборку я думаю всю предоставлять не имеет смысла, во-первых из-за того, что она 74Мб, во-вторых из-за того, что она тривиальна: 3 набора 2-мерных точек, каждый из которых это реализация нормального распределения с заданным мат. ожиданием и дисперсией (на картинке в начале). Точки в файл записаны в случайном порядке. Мат. ожидания и количество точек задаются в функции main генератора.

__gshared это полный аналог глобальных перменных из C/C++. В основном __gshared используется для создания обёрток и биндингов. Модификатор shared является частью системы типов D, он транзитивный (если объект shared, значит и все поля его shared), определяет набор операций (у shared объектов можно вызывать только shared методы). __gshared не относится к системе типов, и в этом плане не безопасен. Использовать его Вы можете только на свой страх и риск (никаких проверок на наличие синхронизации нет, как в C/C++). С точки зрения доступности данных они эквивалентны. А начинается __gshared с двух подчёркиваний, чтобы легче было искать в коде, когда начнутся проблемы =) В итоге, если Вам не нужно использовать разделяемые глобальные переменные с C/C++ кодом, то по сути нет необходимости использовать __gshared.

Новичок в программировании != новичок в D. Я ставил целью разъяснить некоторые моменты людям, знакомым с программированием, но не знакомыми с D. Насчёт велосипедов. Я пробовал организовывать этими стандартными средствами сложные очереди, где одни сообщения должны отрабатываться гарантировано, другие пропускаться по истечению срока, третие идут в обратном направлении и так далее. И понял, что через std.concurrency сложные вещи делать реально сложно. Проще создать несколько очередей (в одном разделяемом объекте) и по ним пускать разные сообщения, а в std.concurrency я не нашёл способа создания нескольких очередей. Соответственно, в простых ситуациях всё что я описал не нужно. Тут же возникает вопрос, чем опасен подход, который я описал и какой конкретно аспект вопроса не расскрыт? Synchronized самостоятельно разруливает синхронизацию каждого метода, immutable объекты нельзя изменять, в разных потока их использовать безопасно, можно это дело сломать, конечно, с помощью cast, но это уже будет на Вашей совести.

Единственный косяк, который мне приходилось отлавливать не косяк по сути. Версия dmd всегда свежее версий frontend'ов gdc и ldc2. Но dmd я пользуюсь как основным, так что не могу полностью гарантировать, что их нет.

Вы не совсем правильно поняли. Если Вам нужны указатели, просто используйте их как Вам угодно: с арифметикой, приведением одних типов указателей к другим и т.д. SafeD это только подмножество языка, включаемое атрибутом @​safe, то есть Вы намерено декларируете в коде, что хотите его использовать и декларируете участок, где оно должно использоваться. Это может быть либо личным желанием оградить себя от ошибок работы с памятью, либо требованием к качеству ПО.

Возможно, а что сейчас принято использовать на С++ для ввода?

Согласен, мой косяк.

Ещё на вики dlang есть список плагинов (по всей видимости не полный).

Не совсем понял проблему. Нужна именно «родная» IDE или достаточно плагина к уже существующей?

К сожалению не могу ответить на этот вопрос, я пользуюсь vim, под него есть хороший плагин dutyl, он использует DCD для автодополнения и поиска документации, dub для выяснения путей, dfmt для форматирования кода, DScanner для проверки синтаксиса, то есть по сути полный фарш (правда, dfmt у меня не завёлся ровно).

добавил про указатели

Просто я не ставил целью сравнить D с C++, хотелось осветить именно эти моменты (хотя про указатели упомянуть наверное стоит, завтра добавлю).