Какие конструкции невозможны с использованием модели Ponylang lock-free?

Ponylang - это новый язык, который не блокируется и не свободен. Мое впечатление состоит в том, что для достижения этого Ponylang рассматривает предложение "если два потока могут видеть один и тот же объект, а затем записи должны запрещать любую другую операцию другим потоком" и использует систему типов для принудительного применения различных особых случаев. Например, существует дескриптор типа, который говорит: "ни один другой поток не может видеть этот объект", и тот, который гласит: "эта ссылка доступна только для чтения" и другие. По общему признанию, мое понимание этого довольно плохое, а документация ponylang на примерах невелика.

Мой вопрос: возможны ли операции с использованием языка, основанного на блокировке, который вообще не переводится в систему на основе ponylang? Кроме того, существуют ли такие операции, которые не могут быть переведены в эффективные конструкции в ponylang?

Ответ 1

[...] существуют ли операции с использованием языка, основанного на блокировке, который вообще не переводится в систему на основе ponylang?

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

Кроме того, существуют ли такие операции, которые не могут быть переведены в эффективные конструкции в ponylang?

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

Это не значит, что во всех случаях модель актера превосходит всех. Это другая модель concurrency, и проблемы решаются по-разному. Например, чтобы вычислить значения N и скопировать результаты в список:

В потоковой модели вы бы
- создать пул потоков,
- создать потокобезопасный список,
- Создайте N задач, совместно использующих список, и
- дождитесь завершения N задач.
В актерской модели вы бы
- создать актер Ожидание значений N,
- создайте N актеров B, разделяющих актера A, и
- дождитесь, когда A создаст список.

Очевидно, что каждая задача добавит значение в список, и каждый актер B отправит значение актеру A. В зависимости от того, как передаются сообщения между участниками, может быть медленнее отправлять значения N, чем блокировать N раз. Обычно это будет медленнее, но, с другой стороны, вы никогда не получите список с непредвиденным размером.

Ответ 2

Я считаю, что он может делать все, что может сделать все, что есть + блокировки. с объектами iso и consume это в основном чистая система передачи сообщений, которая может делать все, что делает система блокировки. Как и в mach3, вы можете делать все, что может сделать linux.