Re: SDL-News: A small question on SDL Concurrency


Subject: Re: SDL-News: A small question on SDL Concurrency
From: Shaheen Shasa (shaheen.shasa#wipro.com)
Date: Wed Jan 30 2002 - 04:30:32 GMT


Hello Rick,

Thanks for your reply.
It has solved some of my issues. Now i understand that it is up to the
implementation to decide the level of concurrency. I am looking more into
it, if i have more hazy areas for discussion i will get back !

Thanks & Regards,
Shaheen

----- Original Message -----
From: "Rick Reed TSE" <rickreed#tseng.co.uk>
To: "SDLnews" <sdlnews#sdl-forum.org>
Cc: "Shaheen Shasa" <shaheen.shasa#wipro.com>
Sent: Tuesday, January 29, 2002 1:57 AM
Subject: Re: SDL-news: A small question on SDL Concurrency

> Shaheen Shasa at shaheen.shasa#wipro.com wrote on 28/01/2002 13:35:
>
> > I have a question regarding the concurrency of process instances inside
a
> > block. Is it mandatory for two process instances inside a block to
execute
> > concurrently at the transition level ? ie can they be executed with
> > "alternating transition semantics" or even different transitions of
PI's need
> > to be concurrent. I am a little bit confused regarding SDL Concurrency
issues
> > , please help !
>
> Is it mandatory for two process instances inside a block to execute
> concurrently at the transition level ?
> --------------------------------------
>
> No.
>
> Is it permitted? Yes. The semantics should be AS IF they are concurrent.
>
> Can they be executed with "alternating transition semantics"
> ------------------------------------------------------------
>
> If you mean: can you allow one transition to run to completion before
> scheduling another instance. That should be OK.
>
> You should consider things in this way:
> -------------------------------------
>
> The semantics of SDL assumes each process instance contained within a
block
> to be executed on a processing resource of its own. Obviously this is
> problematic when there are many process instances or process instances
> created dynamically. Therefore in any real system you would expect a run
> time system to implement the scheduling of process instances on the
limited
> number of processors - often a mono-processor. SDL does not define the
> scheduling algorithm for the run time system.
>
> To be compliant with the SDL semantics a process instance should be ready
to
> run when it is in a state and it is possible to enter one of its
> transitions. Because SDL does not require any particular rate of
execution,
> a run time system is compliant with SDL even if no progress is made in a
> particular instance that is "ready to run". In other words, a process that
> in theory is executing in parallel can be suspended waiting for processing
> resources.
>
> Prior to SDL-2000, a block would normally be implemented by a
mono-processor
> run time system, because communication between process instances in a
block
> is via "non-delaying" communication paths. This communication only
delivers
> signals to the input queue of the receiving process instance, and in
reality
> (even if implemented in micro-program) takes some small but finite amount
of
> time. On the other hand, there is no requirement for a block to be
> implemented on a mono-processor.
>
> SDL does not define how long it takes to execute the consumption of the
> signal and entry into the transition, but the transition that is entered
> must be determined by the order of arrival of the signals in the input
> queue. For example, if both INPUT A and PRIORITY INPUT B cause transitions
> TA and TB (respectively) to be started from the current state and the
> signals arrive in the order signal A then signal B before the process
> instance is actually executed, transition TA will be taken rather then
> transition TB. In other words signal B is logically treated as if it
arrived
> AFTER the transition TA is entered. The run time system and the scheduling
> of transitions therefore has to be implemented so that it takes into
account
> delay in scheduling the process instance.
>
> The run time system and scheduling of transitions also has to take into
> account the semantics of spontaneous transitions and timers.
>
> In SDL-2000 paths can be delaying, but this does not change the logic of
the
> above paragraphs.
>
> Once a process instance is actually executing a transition, the SDL
> semantics assume that the transition "runs to completion". This does not
> mean that execution of the transition cannot be interrupted and suspended
at
> the processor resource scheduling level: it is only required that such
> suspension it transparent at the SDL level.
>
> In SDL-2000 there can be processes defined within a process, and the
> instances of the containing process and contained processes are
interleaved
> at the transition level. It is not allowed for these processes to be
> concurrent.
>
> It is never allowed for different transitions of the same process instance
> to be concurrent. It is allowed (but in practice not required - as
explained
> above - I hope) for different instances of the same process DEFINITION to
be
> concurrent.
>
> It this is still confusing, please ask again and I will try to give a
> different explanation.
>
> --------
>
> This IS a difficult issue to understand and explain, so if any other
expert
> disagrees with what I have written, I request they supply a further (and
> possibly alternative) explanation.
>
> --
> Rick Reed - rickreed#tseng.co.uk
> Tel:+44 1455 55 96 55 Fax:+44 1455 55 96 58 Mob.:+44 7970 50 96 50
>
>




This archive was generated by hypermail 2a23 : Thu May 09 2013 - 16:05:49 GMT