Hi everyone,
I have followed more or less the very long threads on
safety/flexibility/RTT2.0 ...
Still I do not quite understand what is meant by "single thread
serialization", which is so eagerly defended by some :)
Is it implemented by the SequentialActivity? Where can I find details about
that pattern?
Best regards,
Jerome.
What is single thread serialization?
2009/5/13 jerome h <jerome [dot] jh+orocos [..] ...>:
> Hi everyone,
>
> I have followed more or less the very long threads on safety/flexibility/RTT2.0 ...
> Still I do not quite understand what is meant by "single thread serialization", which is so eagerly defended by some :)
>
> Is it implemented by the SequentialActivity? Where can I find details about that pattern?
It is indeed SequentialActivity and it does simulate a multi-threaded
system. I can't directly point to a publication, but I have seen it in
other places, so yes its a pattern. It is however not suitable for
real-time applications, because there's only one thread, which might
execute an arbitrary amount of code in a given time frame.
The messaging is implemented by putting the message on the queue, then
signalling the receiver it got a new message, this signalling calls
into the receiver which gets the message from the queue, processes it
in its updateHook() (which may in turn cause other messages to be
sent) and finally returns to the original sender. As you can see, this
mechanism can even recurse indefinately. To avoid some forms of
recursion, a lock is set around the updateHook such that it isn't
re-entered, and that the message is only queued. You need to look at
the implementation of SequentialActivity to understand what's really
happening.
The end conclusion is however that if you model 'A messages B; B
messages A; which causes A messages B; etc' this mechanism will endup
in an endless loop.But this would also cause your system to go to 100%
in case of real threads...
Peter
What is single thread serialization?
On Wed, 13 May 2009, jerome h wrote:
> I have followed more or less the very long threads on
> safety/flexibility/RTT2.0 ...
> Still I do not quite understand what is meant by "single thread
> serialization", which is so eagerly defended by some :)
>
> Is it implemented by the SequentialActivity? Where can I find details
> about that pattern?
>
The idea is that designing a controler based on the idea of having
different distributed components (interconnected by DataPorts and Events,
and being able to do Method calls on each other) is a Good Thing, but it
turns out that in many systems you could as well execute all components in
one single thread. (Mainly because of efficiency reasons, or because you
want to use only a minimal set of operating system primitives, or even no
OS at all.) That means that all activities in all threads must be scheduled
one after the other ("serialized"), including event handling and accesses
to DataPorts. Orocos has made this possible since a long time (albeit only
on a mostly manual way, without 'toolchain' support).
Herman
What is single thread serialization?
[Sorry for double answer Herman]
Thanks for the answer. Actually, I would like to know how it is implemented.
Where should I look for the implementation, or for documentation on how this
is done?
I am currently working (and worked in the past) with a single threaded
runtime. Everything is done through message passing and makes the code
awkward. So anything that could make a function/method call look
synchronous, although this is handled asynchronously underneath, would
interest me :)
Regards,
Jerome.
On Wed, May 13, 2009 at 11:29 AM, Herman Bruyninckx <
Herman [dot] Bruyninckx [..] ...> wrote:
> On Wed, 13 May 2009, jerome h wrote:
>
> > I have followed more or less the very long threads on
> > safety/flexibility/RTT2.0 ...
> > Still I do not quite understand what is meant by "single thread
> > serialization", which is so eagerly defended by some :)
> >
> > Is it implemented by the SequentialActivity? Where can I find details
> > about that pattern?
> >
> The idea is that designing a controler based on the idea of having
> different distributed components (interconnected by DataPorts and Events,
> and being able to do Method calls on each other) is a Good Thing, but it
> turns out that in many systems you could as well execute all components in
> one single thread. (Mainly because of efficiency reasons, or because you
> want to use only a minimal set of operating system primitives, or even no
> OS at all.) That means that all activities in all threads must be scheduled
> one after the other ("serialized"), including event handling and accesses
> to DataPorts. Orocos has made this possible since a long time (albeit only
> on a mostly manual way, without 'toolchain' support).
>
> Herman
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
What is single thread serialization?
On Wed, 13 May 2009, jerome h wrote:
> [Sorry for double answer Herman]
>
> Thanks for the answer. Actually, I would like to know how it is
> implemented. Where should I look for the implementation, or for
> documentation on how this is done?
As I mentioned: it's mostly manual configuration...
> I am currently working (and worked in the past) with a single threaded
> runtime. Everything is done through message passing and makes the code
> awkward. So anything that could make a function/method call look
> synchronous, although this is handled asynchronously underneath, would
> interest me :)
Why exactly do you say that your code is "made awkward" by message passing?
And why did you resort to message passing in the first place, if you are
single-threaded and hence would have no problem using shared memory (even
without locks...)?
Herman
What is single thread serialization?
On Wed, 13 May 2009, jerome h wrote:
> On Wed, May 13, 2009 at 2:05 PM, Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...Herman [dot] Bruyninckx [..] ...>> wrote:
> On Wed, 13 May 2009, jerome h wrote:
>
>> [Sorry for double answer Herman]
>>
>> Thanks for the answer. Actually, I would like to know how it is
>> implemented. Where should I look for the implementation, or for
>> documentation on how this is done?
> As I mentioned: it's mostly manual configuration...
>
>> I am currently working (and worked in the past) with a single threaded
>> runtime. Everything is done through message passing and makes the code
>> awkward. So anything that could make a function/method call look
>> synchronous, although this is handled asynchronously underneath, would
>> interest me :)
>
> Why exactly do you say that your code is "made awkward" by message passing?
> And why did you resort to message passing in the first place, if you are
> single-threaded and hence would have no problem using shared memory (even
> without locks...)?
>
>
> Sorry to take some of your time, for a matter that is not right now robotics related (although I study the RTT on my free time :)
>
> Message passing makes the code unecessary complicated because you need to
> add a state to your system, even for the simple case where you fire a
> request message, and simply wait for a completion message, and you do not
> expect any other outcome, i.e. the operation may not be interrupted.
Ok, this is more precise than "awkward" :-) And it definitely points to a
use case where "component based" design _seems_ not to make sense.
Note the "_seems_"...: spending some time in trying to come up with good
asynchronous (component-based) design typically leads to also a better
"synchronous" (object-oriented) design! :-)
> What is interesting me with the "single thread serialization", is that
> every RTT primitive is simulated within a single thread. It may be naïve,
> but it looks to me like you are simulating a multi-threaded
> envirronnement within a single thread, without OS nor CPU support.
Yes. Although I would prefer to call it "deployment": this is (or rather
should be) a _configuration_ decision you make when your system is going to
be running on real hardware...
> So I
> wanted to know what kind of code trickery makes this possible?
We don't have such automated configuration support available...
> Using "single thread serialization", is it possible to have a simulated
> thread waiting for an event or message, without blocking the other
> simulated threads. I come from the RTOS world, so when I say event or
> message it may not map well onto RTT primitives, which I do not master
> yet.
>
> You also mentionned in a previous message (1 or 2 weeks old) that
> "synchronous handling makes things much more deterministic (even formally
> verifiable!)". That sparks curiosity into my mind :)
> It is rare to have a system that is formally verifiable in software
> engineering. Would you have pointers to litterature about this?
>
There are many articles about that, see for example
<http://www.inrialpes.fr/sed/Orccad/Presentation/intro-eng.html>
Herman