Actors do not piggy back reactions on a single thread!? Was: Why AsyncFP? Does Scala really need another type of actor? (slides)

I believe this is intentional and necessary. Actors (and even Reactors) act like virtual threads and assure that all your code is thread safe. So if two actors are busy processing a backlog of messages, each will be using a different thread, and any message that is received must be received on the thread the actor is currently using.

Bill La Forge

On Sat, Oct 15, 2011 at 4:15 AM, Sébastien Bocq <sebastien.bocq@gmail.com> wrote:

2011/10/14 Sonnenschein <peter.empen@arcor.de>

As opposed to this, "Programming in Scala" introduces the "react"
method which conserves the thread and allows to host all actors on a
single thread.

I was under the same impression but it doesn't seem the case.

If you look at the source code, each call to send or react results in the scheduling of a new task. The send method calls startSearch, which schedules a task on the underlying executor. The react method calls searchMailbox but set the 'resumeOnSameThread' parameter to false. The subsequent call to resumeReceiver will then also schedule a new task.

I joined a simple thread ring example in attachment. Unless I made a mistake in the code, the trace confirms that a new task is scheduled for each call to send or react. About 20000 tasks are scheduled for 10000 message transfers (e.g. 1 send + 1 react).

Not sure if this is a bug or an intentional change.

Cheers,
Sébastien

Hi Bill,

Actors can use their mailbox as a queue to sequence the execution of their reactions in a thread safe manner.

If you look at the send method, they use the variable waitingFor to check if an actor is busy or not. If the actor is busy, 'waitingFor eq Reactor.waitingForNone', then store the message in the mailbox. If the actor is not busy, take the reaction, set the actor busy, and execute the reaction on the same thread. I'd expect something like this but startSearch always schedules a new task on the underlying thread pool, which can be taken over by any thread.

This is in contradiction to what is explained in both the paper ("The execution
of the closure is piggy-backed on the thread of the sender") and the book (see Peter's reply).

2011/10/15 William la Forge <laforge49@gmail.com>

I believe this is intentional and necessary. Actors (and even Reactors) act like virtual threads and assure that all your code is thread safe. So if two actors are busy processing a backlog of messages, each will be using a different thread, and any message that is received must be received on the thread the actor is currently using.

Bill La Forge

On Sat, Oct 15, 2011 at 4:15 AM, Sébastien Bocq <sebastien.bocq@gmail.com> wrote:

2011/10/14 Sonnenschein <peter.empen@arcor.de>

As opposed to this, "Programming in Scala" introduces the "react"
method which conserves the thread and allows to host all actors on a
single thread.

I was under the same impression but it doesn't seem the case.

If you look at the source code, each call to send or react results in the scheduling of a new task. The send method calls startSearch, which schedules a task on the underlying executor. The react method calls searchMailbox but set the 'resumeOnSameThread' parameter to false. The subsequent call to resumeReceiver will then also schedule a new task.

I joined a simple thread ring example in attachment. Unless I made a mistake in the code, the trace confirms that a new task is scheduled for each call to send or react. About 20000 tasks are scheduled for 10000 message transfers (e.g. 1 send + 1 react).

Not sure if this is a bug or an intentional change.

Cheers,
Sébastien

--
Sébastien

Sébastien,

I've read over the paper. I've seen excerpts from it before but this is the first time I've seen it in its entire. It has a careful distinction between single-threaded actors and multi-threaded actors, where the latter are allowed to perform blocking operations. In section 3.4 we see this:

Because send is not allowed to block, the receiver
(which is resumed) needs to be executed on a different thread. This way, the
sender is not blocked even if the receiver executes a blocking operation.

Contrast this with the quote from section 3.2:

If all actors are running on a single thread, sending
a message to an actor A will resume the execution of receive which caused
A to suspend.

Bill

On Sat, Oct 15, 2011 at 3:03 PM, Sébastien Bocq <sebastien.bocq@gmail.com> wrote:

Hi Bill,

Actors can use their mailbox as a queue to sequence the execution of their reactions in a thread safe manner.

If you look at the send method, they use the variable waitingFor to check if an actor is busy or not. If the actor is busy, 'waitingFor eq Reactor.waitingForNone', then store the message in the mailbox. If the actor is not busy, take the reaction, set the actor busy, and execute the reaction on the same thread. I'd expect something like this but startSearch always schedules a new task on the underlying thread pool, which can be taken over by any thread.

This is in contradiction to what is explained in both the paper ("The execution
of the closure is piggy-backed on the thread of the sender") and the book (see Peter's reply).

2011/10/15 William la Forge <laforge49@gmail.com>

I believe this is intentional and necessary. Actors (and even Reactors) act like virtual threads and assure that all your code is thread safe. So if two actors are busy processing a backlog of messages, each will be using a different thread, and any message that is received must be received on the thread the actor is currently using.

Bill La Forge

On Sat, Oct 15, 2011 at 4:15 AM, Sébastien Bocq <sebastien.bocq@gmail.com> wrote:

2011/10/14 Sonnenschein <peter.empen@arcor.de>

As opposed to this, "Programming in Scala" introduces the "react"
method which conserves the thread and allows to host all actors on a
single thread.

I was under the same impression but it doesn't seem the case.

If you look at the source code, each call to send or react results in the scheduling of a new task. The send method calls startSearch, which schedules a task on the underlying executor. The react method calls searchMailbox but set the 'resumeOnSameThread' parameter to false. The subsequent call to resumeReceiver will then also schedule a new task.

I joined a simple thread ring example in attachment. Unless I made a mistake in the code, the trace confirms that a new task is scheduled for each call to send or react. About 20000 tasks are scheduled for 10000 message transfers (e.g. 1 send + 1 react).

Not sure if this is a bug or an intentional change.

Cheers,
Sébastien

--
Sébastien

So the reason put forward for rescheduling a new task every time is to avoid blocking a sender. It is strange that there is a distinction between send and receive. Furthermore, I don't see why creating a new task makes this any better. If an actor does blocking I/O, a thread will block.

Anyway, thanks a lot for having looked into this with me, I appreciate it.

Sébastien

2011/10/15 William la Forge <laforge49@gmail.com>

Sébastien,

I've read over the paper. I've seen excerpts from it before but this is the first time I've seen it in its entire. It has a careful distinction between single-threaded actors and multi-threaded actors, where the latter are allowed to perform blocking operations. In section 3.4 we see this:

Because send is not allowed to block, the receiver
(which is resumed) needs to be executed on a different thread. This way, the
sender is not blocked even if the receiver executes a blocking operation.

Contrast this with the quote from section 3.2:

If all actors are running on a single thread, sending
a message to an actor A will resume the execution of receive which caused
A to suspend.

Bill

On Sat, Oct 15, 2011 at 3:03 PM, Sébastien Bocq <sebastien.bocq@gmail.com> wrote:

Hi Bill,

Actors can use their mailbox as a queue to sequence the execution of their reactions in a thread safe manner.

If you look at the send method, they use the variable waitingFor to check if an actor is busy or not. If the actor is busy, 'waitingFor eq Reactor.waitingForNone', then store the message in the mailbox. If the actor is not busy, take the reaction, set the actor busy, and execute the reaction on the same thread. I'd expect something like this but startSearch always schedules a new task on the underlying thread pool, which can be taken over by any thread.

This is in contradiction to what is explained in both the paper ("The execution
of the closure is piggy-backed on the thread of the sender") and the book (see Peter's reply).

2011/10/15 William la Forge <laforge49@gmail.com>

I believe this is intentional and necessary. Actors (and even Reactors) act like virtual threads and assure that all your code is thread safe. So if two actors are busy processing a backlog of messages, each will be using a different thread, and any message that is received must be received on the thread the actor is currently using.

Bill La Forge

On Sat, Oct 15, 2011 at 4:15 AM, Sébastien Bocq <sebastien.bocq@gmail.com> wrote:

2011/10/14 Sonnenschein <peter.empen@arcor.de>

As opposed to this, "Programming in Scala" introduces the "react"
method which conserves the thread and allows to host all actors on a
single thread.

I was under the same impression but it doesn't seem the case.

If you look at the source code, each call to send or react results in the scheduling of a new task. The send method calls startSearch, which schedules a task on the underlying executor. The react method calls searchMailbox but set the 'resumeOnSameThread' parameter to false. The subsequent call to resumeReceiver will then also schedule a new task.

I joined a simple thread ring example in attachment. Unless I made a mistake in the code, the trace confirms that a new task is scheduled for each call to send or react. About 20000 tasks are scheduled for 10000 message transfers (e.g. 1 send + 1 react).

Not sure if this is a bug or an intentional change.

Cheers,
Sébastien

--
Sébastien