Files
MapLibreParticleLab/src/mbgl/actor/mailbox.cpp
Anand Thakker cfd436c287 [core] Avoid blocking in Thread<Object> constructor (#12151)
* Introduce AspiringActor, EstablishedActor

This pair of objects represents the two-phase (parent-thread /
child-thread) construction that's needed to support constructing
Thread<Object> without blocking until the child thread is up and
running.

An `AspiringActor<O>` is responsible for:
 - ownership of the actor's `Mailbox`
 - allocating the memory for (but *not* constructing) the target object `O`

Using these two pieces--the mailbox and a stable address for `O`--an
`AspiringActor<O>` can accept messages for the target object, or provide
`ActorRef<O>`s that do so, before the object has actually been
constructed by the corresponding `EstablishedActor<O>`.  (Such messages
are queued in the mailbox until after the object is constructed.)

This allows for an `AspiringActor<O>` to be created and safely used by a
thread other than the one on which the target object will (eventually)
live.

An `EstablishedActor<O>` is responsible for managing the lifetime of the
target object `O` and the open/closed state of the parent's `mailbox`.

The `O` object's lifetime is contained by that of its owning
`EstablishedActor<O>`: the `EstablishedActor` constructor executes the
`O` constructor via "placement new", constructing it at the address
provided by the parent `AspiringActor`, and the `~EstablishedActor`
destructor similarly executes the `~O` destructor (after closing the
mailbox). `EstablishedActor` should therefore live entirely on the
thread intended to own `O`.

* Remove Actor#{invoke,ask}
2018-07-03 17:17:39 -04:00

99 lines
2.4 KiB
C++

#include <mbgl/actor/mailbox.hpp>
#include <mbgl/actor/message.hpp>
#include <mbgl/actor/scheduler.hpp>
#include <cassert>
namespace mbgl {
Mailbox::Mailbox() {
}
Mailbox::Mailbox(Scheduler& scheduler_)
: scheduler(&scheduler_) {
}
void Mailbox::open(Scheduler& scheduler_) {
assert(!scheduler);
// As with close(), block until neither receive() nor push() are in progress, and acquire the two
// mutexes in the same order.
std::lock_guard<std::recursive_mutex> receivingLock(receivingMutex);
std::lock_guard<std::mutex> pushingLock(pushingMutex);
scheduler = &scheduler_;
if (closed) {
return;
}
if (!queue.empty()) {
(*scheduler)->schedule(shared_from_this());
}
}
void Mailbox::close() {
// Block until neither receive() nor push() are in progress. Two mutexes are used because receive()
// must not block send(). Of the two, the receiving mutex must be acquired first, because that is
// the order that an actor will obtain them when it self-sends a message, and consistent lock
// acquisition order prevents deadlocks.
// The receiving mutex is recursive to allow a mailbox (and thus the actor) to close itself.
std::lock_guard<std::recursive_mutex> receivingLock(receivingMutex);
std::lock_guard<std::mutex> pushingLock(pushingMutex);
closed = true;
}
bool Mailbox::isOpen() const { return bool(scheduler); }
void Mailbox::push(std::unique_ptr<Message> message) {
std::lock_guard<std::mutex> pushingLock(pushingMutex);
if (closed) {
return;
}
std::lock_guard<std::mutex> queueLock(queueMutex);
bool wasEmpty = queue.empty();
queue.push(std::move(message));
if (wasEmpty && scheduler) {
(*scheduler)->schedule(shared_from_this());
}
}
void Mailbox::receive() {
std::lock_guard<std::recursive_mutex> receivingLock(receivingMutex);
assert(scheduler);
if (closed) {
return;
}
std::unique_ptr<Message> message;
bool wasEmpty;
{
std::lock_guard<std::mutex> queueLock(queueMutex);
assert(!queue.empty());
message = std::move(queue.front());
queue.pop();
wasEmpty = queue.empty();
}
(*message)();
if (!wasEmpty) {
(*scheduler)->schedule(shared_from_this());
}
}
void Mailbox::maybeReceive(std::weak_ptr<Mailbox> mailbox) {
if (auto locked = mailbox.lock()) {
locked->receive();
}
}
} // namespace mbgl