In RTT v1 is it possible to do the following in a state machine?
transition if Peer.Port.Get() then select SOME_STATE
I've tried everything I can think of in the above syntax, but the only thing that works is to plumb the Peer.Port to the component running the state machine, and then using
transition if Port.Get() then select SOME_STATE
Is anything like the first syntax possible? You can do similar things for Peer's methods and events, but not ports it seems.
Cheers
S
Using peer ports in state machines
On Fri, Oct 7, 2011 at 1:15 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> In RTT v1 is it possible to do the following in a state machine?
>
> transition if Peer.Port.Get() then select SOME_STATE
>
> I've tried everything I can think of in the above syntax, but the only thing that works is to plumb the Peer.Port to the component running the state machine, and then using
>
> transition if Port.Get() then select SOME_STATE
>
> Is anything like the first syntax possible? You can do similar things for Peer's methods and events, but not ports it seems.
It's not possible and unwanted. It would not be thread-safe to call
the Get() method on a peer's port, since there is no protection from
the peer writing that port. You need to have two ports and a
connection in between in order to have this thread-safety. It's the
same for 2.x
Peter
Using peer ports in state machines
On Oct 7, 2011, at 09:54 , Peter Soetens wrote:
> On Fri, Oct 7, 2011 at 1:15 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>> In RTT v1 is it possible to do the following in a state machine?
>>
>> transition if Peer.Port.Get() then select SOME_STATE
>>
>> I've tried everything I can think of in the above syntax, but the only thing that works is to plumb the Peer.Port to the component running the state machine, and then using
>>
>> transition if Port.Get() then select SOME_STATE
>>
>> Is anything like the first syntax possible? You can do similar things for Peer's methods and events, but not ports it seems.
>
> It's not possible and unwanted. It would not be thread-safe to call
> the Get() method on a peer's port, since there is no protection from
> the peer writing that port. You need to have two ports and a
> connection in between in order to have this thread-safety. It's the
> same for 2.x
>
> Peter
Ahhhh yes ... it's obviously been a much longer week than I thought.
It does seem to be a bit of an asymmetry in that you can write that syntax for other items, but not ports. I understand that commands and events are thread-safe in this situation (methods obviously are not necessarily). Seems that the ability to also be able to write
transition if Peer.Port then select SOME_STATE
would be very useful, but would require behind the scenes work, and also bypasses the connection mechanism that the deployer (or similar) offer when connecting ports.
Thanks, Peter
S
Using peer ports in state machines
On Sat, 8 Oct 2011, Stephen Roderick wrote:
> On Oct 7, 2011, at 09:54 , Peter Soetens wrote:
>
>> On Fri, Oct 7, 2011 at 1:15 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>>> In RTT v1 is it possible to do the following in a state machine?
>>>
>>> transition if Peer.Port.Get() then select SOME_STATE
>>>
>>> I've tried everything I can think of in the above syntax, but the only thing that works is to plumb the Peer.Port to the component running the state machine, and then using
>>>
>>> transition if Port.Get() then select SOME_STATE
>>>
>>> Is anything like the first syntax possible? You can do similar things for Peer's methods and events, but not ports it seems.
>>
>> It's not possible and unwanted. It would not be thread-safe to call
>> the Get() method on a peer's port, since there is no protection from
>> the peer writing that port. You need to have two ports and a
>> connection in between in order to have this thread-safety. It's the
>> same for 2.x
>>
>> Peter
>
> Ahhhh yes ... it's obviously been a much longer week than I thought.
>
> It does seem to be a bit of an asymmetry in that you can write that
> syntax for other items, but not ports. I understand that commands and
> events are thread-safe in this situation (methods obviously are not
> necessarily).
Your remarks shows that it will (most probably) never be possible to
provide a framework that can shield developers from _all_ gory details of
distributed component writing... :-( An decent knowledge about the
properties, features and traps of concurrent programming will always be
needed, I guess.
Or do you think otherwise?
Herman
> Seems that the ability to also be able to write
>
> transition if Peer.Port then select SOME_STATE
>
> would be very useful, but would require behind the scenes work, and also bypasses the connection mechanism that the deployer (or similar) offer when connecting ports.
>
> Thanks, Peter
> S
Using peer ports in state machines
On Oct 8, 2011, at 06:26 , Herman Bruyninckx wrote:
> On Sat, 8 Oct 2011, Stephen Roderick wrote:
>
>> On Oct 7, 2011, at 09:54 , Peter Soetens wrote:
>>
>>> On Fri, Oct 7, 2011 at 1:15 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>> In RTT v1 is it possible to do the following in a state machine?
>>>>
>>>> transition if Peer.Port.Get() then select SOME_STATE
>>>>
>>>> I've tried everything I can think of in the above syntax, but the only thing that works is to plumb the Peer.Port to the component running the state machine, and then using
>>>>
>>>> transition if Port.Get() then select SOME_STATE
>>>>
>>>> Is anything like the first syntax possible? You can do similar things for Peer's methods and events, but not ports it seems.
>>>
>>> It's not possible and unwanted. It would not be thread-safe to call
>>> the Get() method on a peer's port, since there is no protection from
>>> the peer writing that port. You need to have two ports and a
>>> connection in between in order to have this thread-safety. It's the
>>> same for 2.x
>>>
>>> Peter
>>
>> Ahhhh yes ... it's obviously been a much longer week than I thought.
>>
>> It does seem to be a bit of an asymmetry in that you can write that
>> syntax for other items, but not ports. I understand that commands and
>> events are thread-safe in this situation (methods obviously are not
>> necessarily).
>
> Your remarks shows that it will (most probably) never be possible to
> provide a framework that can shield developers from _all_ gory details of
> distributed component writing... :-( An decent knowledge about the
> properties, features and traps of concurrent programming will always be
> needed, I guess.
>
> Or do you think otherwise?
No, I completely agree. Once you get beyond toy systems, you run into the gory details. The question is how and where do we _communicate_ such assymetries ...
S
Using peer ports in state machines
On Sat, 8 Oct 2011, Stephen Roderick wrote:
> On Oct 8, 2011, at 06:26 , Herman Bruyninckx wrote:
>
>> On Sat, 8 Oct 2011, Stephen Roderick wrote:
>>
>>> On Oct 7, 2011, at 09:54 , Peter Soetens wrote:
>>>
>>>> On Fri, Oct 7, 2011 at 1:15 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
>>>>> In RTT v1 is it possible to do the following in a state machine?
>>>>>
>>>>> transition if Peer.Port.Get() then select SOME_STATE
>>>>>
>>>>> I've tried everything I can think of in the above syntax, but the only thing that works is to plumb the Peer.Port to the component running the state machine, and then using
>>>>>
>>>>> transition if Port.Get() then select SOME_STATE
>>>>>
>>>>> Is anything like the first syntax possible? You can do similar things for Peer's methods and events, but not ports it seems.
>>>>
>>>> It's not possible and unwanted. It would not be thread-safe to call
>>>> the Get() method on a peer's port, since there is no protection from
>>>> the peer writing that port. You need to have two ports and a
>>>> connection in between in order to have this thread-safety. It's the
>>>> same for 2.x
>>>>
>>>> Peter
>>>
>>> Ahhhh yes ... it's obviously been a much longer week than I thought.
>>>
>>> It does seem to be a bit of an asymmetry in that you can write that
>>> syntax for other items, but not ports. I understand that commands and
>>> events are thread-safe in this situation (methods obviously are not
>>> necessarily).
>>
>> Your remarks shows that it will (most probably) never be possible to
>> provide a framework that can shield developers from _all_ gory details of
>> distributed component writing... :-( An decent knowledge about the
>> properties, features and traps of concurrent programming will always be
>> needed, I guess.
>>
>> Or do you think otherwise?
>
> No, I completely agree. Once you get beyond toy systems, you run into the
> gory details. The question is how and where do we _communicate_ such
> assymetries ...
I have never approached the problem from this (a)ssymetry point of view...
So, I wonder what kind of insights you have learned from it. In other
words, is it worthwhile to introduce the concept of "(a)ssymetry" into
tutorials, and if so, under which form and with what kind of examples?
> S
Herman