选择并发编程语言的一致性模型
我正处于编程语言的设计阶段，目前正在考虑并发方面。 我需要找出一个 一致性模型，即在此编程的并发进程如何处理数据语言。
有两个重要的标准：
- 我更喜欢易用性而不是性能，只要一致性模型允许良好的扩展，
- 我就不能使用需要阻塞或动态内存分配的一致性模型。
我现在的两个候选者一方面是非阻塞软件事务内存，另一个是复制消息传递语义而不共享 a la Erlang。
我特别担心易用性，因此我将提出我反对这两种模型的主要论点。
就 STM 而言，用户必须了解类的哪些成员必须以原子方式发生变化并正确界定原子代码段。 必须编写这些代码，以便它们可以重复未定义的次数，它们可能不执行任何 I/O，可能不调用某些外部函数等。我认为这对于没有经验的程序员来说远非易事。
Erlang 风格的无共享并发很有吸引力，但有一个问题：实时进程无法复制它们发送过来的对象，因为它们无法执行任何内存分配，因此对象必须从一个进程“移动”到另一个进程通过队列。 用户必须意识到，如果一个实时进程对一个对象有两个引用，那么当他将该对象发送到另一个进程时，这两个引用都将被清除。 这有点像弱指针，在任何使用点都可能为空，也可能不为空：这可能会令人惊讶。
我倾向于第二种模型，因为它看起来更容易理解，并且自然地扩展到分布式系统。
您有什么建议？
- 非阻塞软件事务内存？
- Erlang 式并发面临实时约束的困难？
- 还有什么我没有考虑到的吗？
I am in the design phase of a programming language, currently thinking about the concurrency aspects. I need to figure out a consistency model, i.e. how data is handled by concurrent processes programmed in this language.
There are two important criteria:
- I prefer ease-of-use over performance, as long as the consistency model allows good scaling,
- I cannot use a consistency model that requires blocking or dynamic memory allocation.
My two candidates right now are non-blocking software transactional memory on one side, and copying message-passing semantics without sharing a la Erlang.
I'm particularly worried about ease-of-use, so I'll present the major arguments I have against each of these two models.
In the case of STM, the user must understand what members of a class must mutate atomically and correctly delimit atomic code sections. These must be written so that they can be repeated an undefined number of times, they may not perform any I/O, may not call some foreign functions, etc. I see this as far from easy for a non-experienced programmer.
Erlang-style share-nothing concurrency is attractive, but there is a catch: real-time processes cannot copy the objects they send over, because they cannot perform any memory allocation, and so objects have to "move" from one process to the other via queues. The user must be aware that if one real-time process has two references to an object, both those references will be cleared if he sends the object to another process. This is a little like weak pointers that may or may not be null at any point of use: it may be surprising.
I tend towards the second model because it appears easier to understand and it naturally extends to distributed systems.
What do you recommend?
- Non-blocking software transactional memory?
- Erlang-style concurrency with the difficulties of real-time constraints?
- Something else I haven't considered?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我对 Erlang 做了一些工作，但不多，但是尽管无共享消息传递范例对我来说是新的，但我想说它在视觉和物理方面都很容易理解。
如果你的语言要广泛传播，我会说 Erlang 风格至少是我不需要太多工作就能理解的东西。 我认为其他人将能够比 STM 方法更容易地学习和应用这种模型。
我不是根据经验说话，但似乎 Erlang 模型更容易实现，因为它不必处理大量低级内存操作，您只需共享任何内容，并管理之间传递的内存流程。
I have done a little with Erlang, not much, but although the share-nothing message passing paradigm was new for me I would say that it was easy to understand in visual and physical terms.
If your language is to be widespread, I would say that the Erlang-style is at least something I can wrap my mind around without too much work. I assume others will be able to learn and apply that kind of model easier than the STM method.
I'm not speaking from experience, but it seems like the Erlang model would be easier to implement, as it doesn't have to deal with a lot of the low level memory operations, you just share nothing, and manage the memory passing between processes.
我认为单一范式无法解决所有问题并且是不兼容的。 例如，一个应用程序可以对程序的某些部分使用消息传递接口，对其他部分使用STM，对其他更具体的部分使用直接锁定。
您还可以查看连接演算 (JoCaml、Boost.Join），可以将其视为消息传递接口的变体。
I don't think a single paradigm will solve all the issues and are incompatible. For example one application can use the message passing interface for some part of the program and STM for other parts, and direct locking for other more specific parts.
You can also take a look at Join calculus (JoCaml, Boost.Join), which can be considered as a variant of the message passing interface.