We’re here to help you

Menu

Using 'reply'

The 'reply' keyword assigns a value to be returned. The 'reply' keyword also specifies that a blocked thread is allowed to return when all statements in the enclosing action block have been performed.

A 'reply' statement may appear anywhere in an 'action'. Execution of an action block continues after a 'reply' statement is performed. Thread returns occur when the current execution thread reaches the end of the current action block. Then all threads return for which a 'reply' has been executed in the current action block.

Void 'reply' must be omitted in interface models and in non-blocking component action statements. In these cases the void reply is implicit.

Syntax

reply(variable-name); (1)
reply(CONSTANT); (2)
port-name.reply(); (since 2.0.0) (3)
port-name.reply(variable-name); (since 2.0.0) (4)
port-name.reply(CONSTANT); (since 2.0.0) (5)

Explanation:

1 Set the value to be replied to the value currently held by variable-name. (This form applies to interfaces. This form must also be used in component models when the only active thread is associated with the port for the current 'on event' and the current action block is not marked as 'blocking'.)
2 Set the value to be replied to a defined constant (e.g. an enumerated type). (This form applies to interfaces. This form must also be used in component models when the only active thread is associated with the port for the current 'on event' and the current action block is not marked as 'blocking'.)
3 Allow void return on port with name 'port-name'. (This form applies to component models when the current 'action' was specified as 'blocking' or when port 'port-name' is still blocked.)
4 Allow valued return on port with name 'port-name' and assign the value held by 'variable-name' to the reply value for 'port-name'. (This form applies to component models when the 'action' was specified as 'blocking' or when port 'port-name' is still blocked.)
5 Allow valued return on port with name 'port-name' and assign the value held by 'CONSTANT' to the reply value for 'port-name'. (This form applies to component models when the 'action' was specified as 'blocking' or when port 'port-name' is still blocked.)

Examples

Setting an enum as reply value.

This example shows how to set a reply value using an enumerated type.

interface iNetwork
{
// interface to the Network.
// The Network can be requested to send a message by using sendMessage.
// When the message has been sent the Network will inform it's client
// by using messageSent.
  enum MsgRecRes
  {
    OK,
    Failed
  };

  in MsgRecRes sendMessage();
  out void messageSent();

  behaviour
  {
    enum State {Idle, Busy};

    State state = State.Idle;

    [state.Idle]
    // initial or idle state
    {
      on sendMessage: // the interface must cover the case that a message is received successfully:
      {
        reply(MsgRecRes.OK);
        state = State.Busy;
      }
      on sendMessage: // the interface must cover the case that a message is not received successfully:
      {
        reply(MsgRecRes.Failed);
      }
    }
    ...
  }
}

Thread signalling

Component CA illustrates the use of 'reply' to signal blocked thread release. The action statement in 'on pp.request*' are marked as 'blocking' and do not contain a reply statement. A thread calling pp.request_reply or pp.request_notify will block after calling rp.request. That thread returns when the action statement for 'on rp.accept' or 'on rp.reject' have been performed.

interface IBlockingRequest
{
  in bool request_reply();
  in void request_notify();
  out void accept();
  out void reject();

  behaviour
  {
    on request_reply: reply(true);
    on request_reply: reply(false);
    on request_notify: accept;
    on request_notify: reject;
  }
}

interface INonBlockingRequest
{
  in void request();
  out void accept();
  out void reject();
  behaviour
  {
    bool is_considering = false;
    on request: is_considering = true;
    [is_considering] on inevitable: {accept; is_considering = false;}
    [is_considering] on inevitable: {reject; is_considering = false;}
  }
}

component CA
{
  provides IBlockingRequest pp;
  requires INonBlockingRequest rp;

  behaviour
  {
    bool reply_requested = true;
    on pp.request_reply(): blocking {reply_requested = true; rp.request();}
    on pp.request_notify(): blocking {reply_requested = false; rp.request();}

    [reply_requested] on rp.accept(): pp.reply(true);
    [!reply_requested] on rp.accept(): {pp.accept(); pp.reply();}

    [reply_requested] on rp.reject(): {bool b = false; pp.reply(b);}
    [!reply_requested] on rp.reject(): {pp.reject(); pp.reply();}
  }
}

If you have questions that weren’t answered by this Guide,
let our support team help you out.

Enjoy this article? Don't forget to share.
google-site-verification:google656c7703ab521151.html