If anyone want exposure to programming with this kind of model, a good idea might be to look at Go lang. This model is very similar to the Go's concurrency model. In Go, you can spawn lightweight threads called Go routines which communicate with each other through channels which are basically buffers. This model isn't exclusive to Go, and it has been implemented it in Python, C++, and other languages, but it is a primitive built into Go which is kind of cool.
jiajunbl
I agree with @jcarchi that go-lang is a good language to play around with. Channels are really nice to use as synchronization objects. It is important (and also cool) to note that go-lang is not limited to this exact model in a sense that it also has potential to allow shared address spaces over go routines.
Another interesting thing since go was brought up is that managing user-space threads is a generally hard task to get right and in go-lang, if we are just using 1 CPU, we could have a single while (1) {} thread stall all threads in the program. Go-lang uses a M:N threading model (http://en.wikipedia.org/wiki/Thread_(computing)#M:N_.28Hybrid_threading.29)
To add on, another feature which does this type of mailbox system for us is IPC (and on a distributed/network level, RPC).
Azerty
One interesting programming model using this abstraction is the actor model. The idea is that everything is an actor, each actor has a state, and each actor may receive or send messages to other actors, as well as instantiate new actors. Actors behave regarding the messages they receive (asynchronously), and their state changes accordingly. It is interesting for concurrency challenges, as actors are inherently concurrent: it would be lock free at the level of a programmer using an Actor API for instance. The disadvantage is the asynchronous nature of this model.
rofer
I'm curious whether or not the abstraction specifies if send can block. I suspect this may be up to the implementation, but I'm not sure.
I see two ways this could work. Either send blocks until the other thread calls receive or send puts the message in a buffer for the the other thread and continues executing.
kayvonf
@rofer. Your intuition is correct. There are several variants of send, both blocking and non-blocking, and the semantics of these operations are part of their abstraction, not just their implementation. (As a program you may want to know if, at the return from send, the receivers has received the messaged yet or not.) You'll write programs using message passing in Assignment 3, and as preparation for that assignment we'll talk in detail about a couple of variants of send/recv.
vrazdan
I still do not fully understand how send/receive can be implemented. How can thread 2 know the message id of the message sent from thread 1, without having prior communication to know what value to expect? And if these were to be non-blocking methods, won't the overhead of a central manager who handles routing of all the messages between threads quickly become unwieldy? The later slides talk about how there doesn't need to be hardware support for the messages, but to have software be the manager seems as if it would act as a bottleneck and potentially slow down the whole system.
If anyone want exposure to programming with this kind of model, a good idea might be to look at Go lang. This model is very similar to the Go's concurrency model. In Go, you can spawn lightweight threads called Go routines which communicate with each other through channels which are basically buffers. This model isn't exclusive to Go, and it has been implemented it in Python, C++, and other languages, but it is a primitive built into Go which is kind of cool.
I agree with @jcarchi that go-lang is a good language to play around with. Channels are really nice to use as synchronization objects. It is important (and also cool) to note that go-lang is not limited to this exact model in a sense that it also has potential to allow shared address spaces over go routines.
Another interesting thing since go was brought up is that managing user-space threads is a generally hard task to get right and in go-lang, if we are just using 1 CPU, we could have a single while (1) {} thread stall all threads in the program. Go-lang uses a M:N threading model (http://en.wikipedia.org/wiki/Thread_(computing)#M:N_.28Hybrid_threading.29)
To add on, another feature which does this type of mailbox system for us is IPC (and on a distributed/network level, RPC).
One interesting programming model using this abstraction is the actor model. The idea is that everything is an actor, each actor has a state, and each actor may receive or send messages to other actors, as well as instantiate new actors. Actors behave regarding the messages they receive (asynchronously), and their state changes accordingly. It is interesting for concurrency challenges, as actors are inherently concurrent: it would be lock free at the level of a programmer using an Actor API for instance. The disadvantage is the asynchronous nature of this model.
I'm curious whether or not the abstraction specifies if send can block. I suspect this may be up to the implementation, but I'm not sure.
I see two ways this could work. Either send blocks until the other thread calls receive or send puts the message in a buffer for the the other thread and continues executing.
@rofer. Your intuition is correct. There are several variants of send, both blocking and non-blocking, and the semantics of these operations are part of their abstraction, not just their implementation. (As a program you may want to know if, at the return from send, the receivers has received the messaged yet or not.) You'll write programs using message passing in Assignment 3, and as preparation for that assignment we'll talk in detail about a couple of variants of send/recv.
I still do not fully understand how send/receive can be implemented. How can thread 2 know the message id of the message sent from thread 1, without having prior communication to know what value to expect? And if these were to be non-blocking methods, won't the overhead of a central manager who handles routing of all the messages between threads quickly become unwieldy? The later slides talk about how there doesn't need to be hardware support for the messages, but to have software be the manager seems as if it would act as a bottleneck and potentially slow down the whole system.