From 030fe28fa6f9341df20607b8e00c8d9b324d10bd Mon Sep 17 00:00:00 2001 From: Martin Quinson Date: Sun, 14 Aug 2016 13:06:33 +0200 Subject: [PATCH] improve s4u::Mailbox documentation --- include/simgrid/s4u/mailbox.hpp | 102 +++++++++++++++++++++++++++----- 1 file changed, 87 insertions(+), 15 deletions(-) diff --git a/include/simgrid/s4u/mailbox.hpp b/include/simgrid/s4u/mailbox.hpp index 88206d6328..78354d4936 100644 --- a/include/simgrid/s4u/mailbox.hpp +++ b/include/simgrid/s4u/mailbox.hpp @@ -16,12 +16,83 @@ namespace simgrid { namespace s4u { -/** @brief Mailboxes +/** @brief Mailboxes: Network rendez-vous points. + * @ingroup s4u_api * - * Rendez-vous point for network communications, similar to URLs on which you could post and retrieve data. - * They are not network locations: you can post and retrieve on a given mailbox from anywhere on the network. - * You can access any mailbox without any latency. The network delay are only related to the location of the - * sender and receiver. + * @tableofcontents + * + * @section s4u_mb_what What are mailboxes + * + * Rendez-vous point for network communications, similar to URLs on + * which you could post and retrieve data. Actually, the mailboxes are + * not involved in the communication once it starts, but only to find + * the contact with which you want to communicate. + + * Here are some mechanisms similar to the mailbox in other + * communication systems: The phone number, which allows the caller to + * find the receiver. The twitter hashtag, which help senders and + * receivers to find each others. In TCP, the pair {host name, host + * port} to which you can connect to find your interlocutor. In HTTP, + * URLs through which the clients can connect to the servers. + * + * One big difference with most of these systems is that usually, no + * actor is the exclusive owner of a mailbox, neither in sending nor + * in receiving. Many actors can send into and/or receive from the + * same mailbox. This is a big difference to the socket ports for + * example, that are definitely exclusive in receiving. + * + * A big difference with twitter hashtags is that SimGrid does not + * offer easy support to broadcast a given message to many + * receivers. So that would be like a twitter tag where each message + * is consumed by the first coming receiver. + * + * The mailboxes are not located on the network, and you can access + * them without any latency. The network delay are only related to the + * location of the sender and receiver once the match between them is + * done on the mailbox. This is just like the phone number that you + * can use locally, and the geographical distance only comes into play + * once you start the communication by dialling this number. + * + * @section s4u_mb_howto How to use mailboxes? + * + * Any existing mailbox can be retrieve from its name (which are + * unique strings, just like with twitter tags). This results in a + * versatile mechanism that can be used to build many different + * situations. + * + * For something close to classical socket communications, use + * "hostname:port" as mailbox names, and make sure that only one actor + * reads into that mailbox. It's hard to build a prefectly realistic + * model of the TCP sockets, but most of the time, this system is too + * cumbersome for your simulations anyway. You probably want something + * simpler, that turns our to be easy to build with the mailboxes. + * + * Many examples in the archive use a sort of yellow page system where + * the mailbox names are the name of the service (such as "worker", + * "master" or "reducer"). That way, you don't have to know where your + * peer is located to contact it. You don't even need its name. Its + * function is enough for that. This also gives you some sort of load + * balancing for free if more than one actor pulls from the mailbox: + * the first relevant actor that can deal with the request will handle + * it. + * + * @section s4u_mb_receiver Declaring a receiving actor + * + * The last twist is that by default in the simulator, the data starts + * to be exchanged only when both the sender and the receiver are + * declared while in real systems (such as TCP or MPI), the data + * starts to flow as soon as the sender posts it, even if the receiver + * did not post its recv() yet. This can obviously lead to bad + * simulation timings, as the simulated communications do not start at + * the exact same time than the real ones. + * + * If the simulation timings are very important to you, you can + * declare a specific receiver to a given mailbox (with the function + * setReceiver()). That way, any send() posted to that mailbox will + * start as soon as possible, and the data will already be there on + * the receiver host when the receiver actor posts its receive(). + * + * @section s4u_mb_api The API */ XBT_PUBLIC_CLASS Mailbox { friend Comm; @@ -32,37 +103,38 @@ XBT_PUBLIC_CLASS Mailbox { Mailbox(smx_mailbox_t mbox): pimpl_(mbox) {} - // We don't have to manage the lifetime of mailboxes: + /** private function to manage the mailboxes' lifetime (see @ref s4u_raii) */ friend void intrusive_ptr_add_ref(Mailbox*) {} + /** private function to manage the mailboxes' lifetime (see @ref s4u_raii) */ friend void intrusive_ptr_release(Mailbox*) {} public: - smx_mailbox_t getImpl() { return pimpl_; } // FIXME: make me protected - + /** private function, do not use. FIXME: make me protected */ + smx_mailbox_t getImpl() { return pimpl_; } - /** Get the name of that mailbox */ + /** Gets the name of that mailbox */ const char *getName(); - /** Retrieve the mailbox associated to the given string (as a C string) */ + /** Retrieve the mailbox associated to the given C string */ static MailboxPtr byName(const char *name); - /** Retrieve the mailbox associated to the given string (as a C++ string) */ + /** Retrieve the mailbox associated to the given C++ string */ static MailboxPtr byName(std::string name); /** Returns whether the mailbox contains queued communications */ bool empty(); - /** Returns the first element in the queue, or nullptr if none is there */ + /** Gets the first element in the queue (without dequeuing it), or nullptr if none is there */ smx_activity_t front(); - /** Declare that the specified process is a permanent receiver on that mailbox + /** Declare that the specified actor is a permanent receiver on that mailbox * * It means that the communications sent to this mailbox will start flowing to * its host even before he does a recv(). This models the real behavior of TCP * and MPI communications, amongst other. */ - void setReceiver(ActorPtr process); + void setReceiver(ActorPtr actor); - /** Return the process declared as permanent receiver, or nullptr if none **/ + /** Return the actor declared as permanent receiver, or nullptr if none **/ ActorPtr receiver(); }; -- 2.20.1