We have several types of bags that can be directly used in the application. To do so, you just have to use their name in the object description (See file).


Contrary to a set, a multiset is a bag that allows several identical resources to be present at the same time in the bag. In order to allow flexibility in this bag we define aspects that modify parts of the semantic of this bag. In fact this modification of the semantic is done by modifying the individual semantic associated to the operation of the protocol rd(), get(), put(), ...

You may find here after the list of aspects


  • It is possible to split in two the resources managed by a MultiSet thanks to the KeyLength parameter.
  • By setting to the KeyLength parameter we can express the fact we want that we have only one resource with the n first fields.
  • for instance if we have a MultiSet that manage tuple of length 5 and whose KeyLength parameter is 3 the it is not possible to have in the bag at the same time ('1','2','3','a','b') and ('1','2','3','c','d'). The in() operation of ('1','2','3','c','d') will cause the removal of ('1','2','3','a','b') and the insertion of ('1','2','3','c','d').
  • This is very convenient because
    • with KeyLength = 0 we can have a normal multiset
    • with KeyLength = (or -1 for convenience) we have a set
    • with KeyLength = n we can define unique keys as part of the resources.
    • ::(default is 0)

The KeyLength allows to range from classical multiset to set. Using a multiSet is useful when we want to have several times the same resource. For instance consider a bag that model a purse. You can have several exemplary on the same coin.

On the contrary, a set is useful when you want to ensure the each kind of resource is in a unique exemplary in the bag. For instance, consider a bag that model all the types of sensor you can have into your system. Once each sensor has inserted its type in the bag, you automatically have the list of available type of sensors without any particular treatment.

Finally, yeyed multiset, with a part of the resource that is considered as a key ensures that you will have a single resource corresponding to the key. For instance, you can consider a bag that reflects the status of a group of sensors. If we set the keylength to 1 and the first field is the sensor name, each time a new resource coming from a sensor is inserted to reflect the current state, the previous state is overwritten. This ensures that you will be able to access all the time to the last state of the sensor.


  • it is possible to define if we want to be blocked when a rd() is performed and no corresponding resource is present or on the contrary we want the operation to return the information that no more resources are available.
    • with Blocking = True, the rd() is blocked until further compatible resource become available
    • with Blocking = False, the rd() is non blocking and the virtual resource no-more-resource is returned
    • ::(default True)

The Blocking aspect allows to deal with 2 different behaviors in a rule.

Blocking = True, the system wait until a resource become available. For instance, if I have a rule that wait for the termination of a print to send an e-mail to the owner. It is useful to wait. On the contrary, if I have to print something, preferably on a color printer but I accept a black and white if no color printer is available. In this case, I will use Blocking = False for the search of the color printer in order to cut the rule for printing in color. Then, the alternative rule with black and white will do the job.


  • it is possible to specify if we want that the resource is effectively removed when the get() is confirmed in the transaction or not.
    • with ReadOnly = False, the resource is physically removed when the confirm() corresponding to the get() is received by the bag
    • with ReadOnly = True, on the external point of view it is identical to the previous description, but for the internal the resource is not physically removed.
    • ::(default False)

The ReadOnly aspect allows to change a classical bag to a bag that would have an infinite number of any of its resources. It is like when you do shopping of the Internet. It is not because you buy an hard disk that the shop do no longer offer this hard disk on its web page (ReadOnly = True). On the contrary, for the management of the stock the special exemplary you just bought disappear from the stock (ReadOnly = False).


  • it is possible to specify if we want or not perform the first phase of the transaction (the get() operation).
    • with Transactional = True, it is the default behavior previously described.
    • with Transactional = False, the verification of the first phase is not done but the result is always true. The second phase is performed with the normal behavior.
    • ::(default True)

The main interest of that is performance, if we know by advance that the result of the first phase of the transaction is always positive, it is not required to pay the price to ask the bag.


We can summarize the impact of the aspects on the basic operations of the protocol

| Impact of the aspects on the operations | ReadOnly | Transactional | KeyLength | Blocking| |---|---|---|---|---|---| | operation concerned | confirm() after get() | get() and put() | confirm() after put() | rd() | |default value | False | True | 0 | True | | default behavior | remove resource | get() and put() performed | insert resource in any case | block until compatible resource appears| | alternate behavior | resource is not physically removed | get() and put() skipped, return always ok | insert resource only if key is different | non blocking|