include/simgrid/s4u/Mailbox.hpp

   1 /* Copyright (c) 2006-2015. The SimGrid Team. All rights reserved.          */
   2
   3 /* This program is free software; you can redistribute it and/or modify it
   4  * under the terms of the license (GNU LGPL) which comes with this package. */
   5
   6 #ifndef SIMGRID_S4U_MAILBOX_HPP
   7 #define SIMGRID_S4U_MAILBOX_HPP
   8
   9 #include <string>
  10
  11 #include <xbt/base.h>
  12
  13 #include <simgrid/s4u/forward.hpp>
  14 #include <simgrid/s4u/Actor.hpp>
  15
  16 namespace simgrid {
  17 namespace s4u {
  18
  19 /** @brief Mailboxes: Network rendez-vous points.
  20  *  @ingroup s4u_api
  21  *
  22  * @tableofcontents
  23  *
  24  * @section s4u_mb_what What are mailboxes
  25  *
  26  * Rendez-vous point for network communications, similar to URLs on
  27  * which you could post and retrieve data. Actually, the mailboxes are
  28  * not involved in the communication once it starts, but only to find
  29  * the contact with which you want to communicate.
  30
  31  * Here are some mechanisms similar to the mailbox in other
  32  * communication systems: The phone number, which allows the caller to
  33  * find the receiver. The twitter hashtag, which help senders and
  34  * receivers to find each others. In TCP, the pair {host name, host
  35  * port} to which you can connect to find your interlocutor. In HTTP,
  36  * URLs through which the clients can connect to the servers.
  37  *
  38  * One big difference with most of these systems is that usually, no
  39  * actor is the exclusive owner of a mailbox, neither in sending nor
  40  * in receiving. Many actors can send into and/or receive from the
  41  * same mailbox.  This is a big difference to the socket ports for
  42  * example, that are definitely exclusive in receiving.
  43  *
  44  * A big difference with twitter hashtags is that SimGrid does not
  45  * offer easy support to broadcast a given message to many
  46  * receivers. So that would be like a twitter tag where each message
  47  * is consumed by the first coming receiver.
  48  *
  49  * The mailboxes are not located on the network, and you can access
  50  * them without any latency. The network delay are only related to the
  51  * location of the sender and receiver once the match between them is
  52  * done on the mailbox. This is just like the phone number that you
  53  * can use locally, and the geographical distance only comes into play
  54  * once you start the communication by dialling this number.
  55  *
  56  * @section s4u_mb_howto How to use mailboxes?
  57  *
  58  * Any existing mailbox can be retrieve from its name (which are
  59  * unique strings, just like with twitter tags). This results in a
  60  * versatile mechanism that can be used to build many different
  61  * situations.
  62  *
  63  * For something close to classical socket communications, use
  64  * "hostname:port" as mailbox names, and make sure that only one actor
  65  * reads into that mailbox. It's hard to build a prefectly realistic
  66  * model of the TCP sockets, but most of the time, this system is too
  67  * cumbersome for your simulations anyway. You probably want something
  68  * simpler, that turns our to be easy to build with the mailboxes.
  69  *
  70  * Many examples in the archive use a sort of yellow page system where
  71  * the mailbox names are the name of the service (such as "worker",
  72  * "master" or "reducer"). That way, you don't have to know where your
  73  * peer is located to contact it. You don't even need its name. Its
  74  * function is enough for that. This also gives you some sort of load
  75  * balancing for free if more than one actor pulls from the mailbox:
  76  * the first relevant actor that can deal with the request will handle
  77  * it.
  78  *
  79  * @section s4u_mb_receiver Declaring a receiving actor
  80  *
  81  * The last twist is that by default in the simulator, the data starts
  82  * to be exchanged only when both the sender and the receiver are
  83  * declared while in real systems (such as TCP or MPI), the data
  84  * starts to flow as soon as the sender posts it, even if the receiver
  85  * did not post its recv() yet. This can obviously lead to bad
  86  * simulation timings, as the simulated communications do not start at
  87  * the exact same time than the real ones.
  88  *
  89  * If the simulation timings are very important to you, you can
  90  * declare a specific receiver to a given mailbox (with the function
  91  * setReceiver()). That way, any send() posted to that mailbox will
  92  * start as soon as possible, and the data will already be there on
  93  * the receiver host when the receiver actor posts its receive().
  94  *
  95  * @section s4u_mb_api The API
  96  */
  97 XBT_PUBLIC_CLASS Mailbox {
  98   friend Comm;
  99   friend simgrid::s4u::Engine;
 100   friend simgrid::simix::Mailbox;
 101
 102   simgrid::simix::Mailbox *pimpl_;
 103
 104   Mailbox(smx_mailbox_t mbox): pimpl_(mbox) {}
 105
 106   /** private function to manage the mailboxes' lifetime (see @ref s4u_raii) */
 107   friend void intrusive_ptr_add_ref(Mailbox*) {}
 108   /** private function to manage the mailboxes' lifetime (see @ref s4u_raii) */
 109   friend void intrusive_ptr_release(Mailbox*) {}
 110 public:
 111   /** private function, do not use. FIXME: make me protected */
 112   smx_mailbox_t getImpl() { return pimpl_; }
 113
 114   /** Gets the name of that mailbox */
 115   const char *getName();
 116
 117   /** Retrieve the mailbox associated to the given C string */
 118   static MailboxPtr byName(const char *name);
 119
 120   /** Retrieve the mailbox associated to the given C++ string */
 121   static MailboxPtr byName(std::string name);
 122
 123   /** Returns whether the mailbox contains queued communications */
 124   bool empty();
 125
 126   /** Gets the first element in the queue (without dequeuing it), or nullptr if none is there */
 127   smx_activity_t front();
 128
 129   /** Declare that the specified actor is a permanent receiver on that mailbox
 130    *
 131    * It means that the communications sent to this mailbox will start flowing to
 132    * its host even before he does a recv(). This models the real behavior of TCP
 133    * and MPI communications, amongst other.
 134    */
 135   void setReceiver(ActorPtr actor);
 136
 137   /** Return the actor declared as permanent receiver, or nullptr if none **/
 138   ActorPtr receiver();
 139 };
 140
 141 }} // namespace simgrid::s4u
 142
 143 #endif /* SIMGRID_S4U_MAILBOX_HPP */