Многопоточный (параллельный) доступ к встроенным объектам Common Lisp - PullRequest
2 голосов
/ 26 марта 2019

Тема многопоточного доступа к объектам Lisp появилась в другом посте на https://stackoverflow.com/posts/comments/97440894?noredirect=1,, но как побочный вопрос, и я надеюсь на дальнейшие разъяснения.

В общем, функции Lisp (и специальные формы, макросы и т. Д.), Похоже, естественно делятся на методы доступа и модификаторы объектов. Модификаторы общих объектов явно проблематичны в многопоточных приложениях, так как обновления, происходящие в одно и то же время, могут мешать друг другу (требуя защитных блокировок, атомарных операций и т. Д.).

Но вопрос о возможных помехах доступа кажется менее ясным. Конечно, любой аксессор может быть написан с включением скрытого модифицирующего кода, но я хотел бы думать, что базовые операции аксессора Lisp (как указано в CLHS и реализованы для различных платформ) этого не делают. Тем не менее, я подозреваю, что может быть очень мало исключений по соображениям эффективности - исключений, о которых было бы полезно знать, если иным образом использовать многопоточный код без защиты. (Исключениями, о которых я говорю, являются , а не операции, такие как maphash, которые могут использоваться и как средство доступа, и как модификатор.)

Было бы полезно, если бы кто-либо, имеющий опыт реализации, мог указать хотя бы на одну встроенную операцию только для доступа (скажем, в SBCL или другом источнике), которая включает потенциально проблемную модификацию. Я знаю, что гарантии трудно получить, но эвристическое руководство также полезно.

1 Ответ

0 голосов
/ 30 марта 2019

Любой код, который делает это, будет ошибкой в ​​реализации, которая поддерживает многопоточность. SBCL защищает функции, которые не являются поточно-ориентированными, с помощью знаменитого *world-lock*.

Если у вас есть реальная причина желать неизменной структуры, используйте defconstant с defstruct только для чтения. (defstruct number (value :read-only t))

(defconstant +five+ (make-number 5))

...