Hi,
I'd like to ask you something about the acquisition of events in rFSM: I
looked at the code in *rfsm_rtt.lua* and specifically at this function:
function gen_read_str_events(...)
local str_ev = rtt.Variable("string")
local function read_events(tgttab, port)
local fs
while true do
*fs = port:read(str_ev)*
if fs == 'NewData' then tgttab[#tgttab+1] = str_ev:tolua()
else break
end -- OldData or NoData
end
end
local ports = {...}
assert(#ports > 0, "no ports given")
rFSM - Simultaneous events
On Mon, 2 Jul 2012, Nicola Preda wrote:
> Hi,
> I'd like to ask you something about the acquisition of events in rFSM: I
> looked at the code in *rfsm_rtt.lua* and specifically at this function:
>
>
> function gen_read_str_events(...)
> local str_ev = rtt.Variable("string")
> local function read_events(tgttab, port)
> local fs
>
> while true do
> *fs = port:read(str_ev)*
> if fs == 'NewData' then tgttab[#tgttab+1] = str_ev:tolua()
> else break
> end -- OldData or NoData
>
> end
> end
> local ports = {...}
> assert(#ports > 0, "no ports given")
> -- check its all ports
> return function ()
> local res = {}
> for _,port in ipairs(ports) do read_events(res, port) end
> return res
> end
> end
>
>
> from what I understood, two events are considered simultaneous when they
> are sent in a time shorter than the one needed to execute the first line of
> the while loop of the code above (i.e. *fs = port:read(str_ev))*. Am I
> wrong? And if it is true, isn't this kind of mechanism quite hardware
> dependent? What I mean is that if you send two consecutive*
> events.write("e_foo")* you will have two simultaneous events but you will
> have the same behaviour if you send events from a periodic component to an
> another at a frequency greater than 1KHz (at least on mine machine). Does
> it make sense to you?
I think your analysis is correct. And that's fine: an event-based system
Coordination should be _robust_ against timing issues. In other words, if
your discrete event logic depends on timing, your system is prone to lots
of difficult to trace error behaviours.
Is this the case you are confronted with?
> Thank you for your attention.
>
> Best regards,
> Nicola Preda
Herman
rFSM - Simultaneous events
On 2 July 2012 18:38, Herman Bruyninckx
<Herman [dot] Bruyninckx [..] ...> wrote:
>> from what I understood, two events are considered simultaneous when they
>> are sent in a time shorter than the one needed to execute the first line of
>> the while loop of the code above (i.e. *fs = port:read(str_ev))*. Am I
>> wrong? And if it is true, isn't this kind of mechanism quite hardware
>> dependent? What I mean is that if you send two consecutive*
>> events.write("e_foo")* you will have two simultaneous events but you will
>> have the same behaviour if you send events from a periodic component to an
>> another at a frequency greater than 1KHz (at least on mine machine). Does
>> it make sense to you?
>
> I think your analysis is correct. And that's fine: an event-based system
> Coordination should be _robust_ against timing issues. In other words, if
> your discrete event logic depends on timing, your system is prone to lots
> of difficult to trace error behaviours.
This is probably a gross misuse of the word, but I like to think of
this in terms of quantisation of events. It's the same meaning, but
sounds cooler. ;)
Geoff
rFSM - Simultaneous events
On Tue, 3 Jul 2012, Geoffrey Biggs wrote:
> On 2 July 2012 18:38, Herman Bruyninckx
> <Herman [dot] Bruyninckx [..] ...> wrote:
>>> from what I understood, two events are considered simultaneous when they
>>> are sent in a time shorter than the one needed to execute the first line of
>>> the while loop of the code above (i.e. *fs = port:read(str_ev))*. Am I
>>> wrong? And if it is true, isn't this kind of mechanism quite hardware
>>> dependent? What I mean is that if you send two consecutive*
>>> events.write("e_foo")* you will have two simultaneous events but you will
>>> have the same behaviour if you send events from a periodic component to an
>>> another at a frequency greater than 1KHz (at least on mine machine). Does
>>> it make sense to you?
>>
>> I think your analysis is correct. And that's fine: an event-based system
>> Coordination should be _robust_ against timing issues. In other words, if
>> your discrete event logic depends on timing, your system is prone to lots
>> of difficult to trace error behaviours.
>
> This is probably a gross misuse of the word, but I like to think of
> this in terms of quantisation of events. It's the same meaning, but
> sounds cooler. ;)
It definitely sounds cooler :-) But "quantisation" makes me think about
inherent stochasticity and Heisenberg's principle, which need not fit very
well as a metaphor to event processing...
Although there _is_ a case to be made for probabilistic FSMs!
> Geoff
Herman