* [Ravenscar] run tasks on events @ 2008-05-28 19:14 Sebastian Hanigk 2008-05-28 23:47 ` jimmaureenrogers ` (3 more replies) 0 siblings, 4 replies; 19+ messages in thread From: Sebastian Hanigk @ 2008-05-28 19:14 UTC (permalink / raw) Hello, sorry if this is a stupid question, but as newcomer to Ada I've stumbled over the following problem: having read a bit on HAL/S which has task scheduling depending on signals and conditions, I'm a bit at loss how to implement such functionality in Ada under the Ravenscar profile (no dynamic task spawning). The example from the HAL/S user guide were tasks running e.g. only in the free-fall or ascent/descent phase, started and terminated by signals. Thanks for any help or pointers! Sebastian ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: run tasks on events 2008-05-28 19:14 [Ravenscar] run tasks on events Sebastian Hanigk @ 2008-05-28 23:47 ` jimmaureenrogers 2008-05-29 10:35 ` Sebastian Hanigk 2008-05-29 3:16 ` ahab ` (2 subsequent siblings) 3 siblings, 1 reply; 19+ messages in thread From: jimmaureenrogers @ 2008-05-28 23:47 UTC (permalink / raw) On May 28, 1:14 pm, Sebastian Hanigk <han...@in.tum.de> wrote: > Hello, > > sorry if this is a stupid question, but as newcomer to Ada I've stumbled > over the following problem: having read a bit on HAL/S which has task > scheduling depending on signals and conditions, I'm a bit at loss how to > implement such functionality in Ada under the Ravenscar profile (no > dynamic task spawning). > > The example from the HAL/S user guide were tasks running e.g. only in > the free-fall or ascent/descent phase, started and terminated by > signals. > > Thanks for any help or pointers! > > Sebastian You can create a task which suspends until the ascent/descent phase. Simply have the task suspend on an accept statement. The task will complete its execution upon execution of a rendezvous associated with the accept statement. Alternately, the task can start out executing and be suspended upon a call to a blocked protected entry. None of this requires dynamic task allocation. Jim Rogers ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: run tasks on events 2008-05-28 23:47 ` jimmaureenrogers @ 2008-05-29 10:35 ` Sebastian Hanigk 0 siblings, 0 replies; 19+ messages in thread From: Sebastian Hanigk @ 2008-05-29 10:35 UTC (permalink / raw) "jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net> writes: > You can create a task which suspends until the ascent/descent phase. > Simply have the task suspend on an accept statement. The task will > complete its execution upon execution of a rendezvous associated with > the accept statement. Alternately, the task can start out executing > and be suspended upon a call to a blocked protected entry. Thanks for the pointers! Albeit - as stated in my sibling response - it lacks the elegance of HAL/S' signal-dependent scheduling. Sebastian ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: run tasks on events 2008-05-28 19:14 [Ravenscar] run tasks on events Sebastian Hanigk 2008-05-28 23:47 ` jimmaureenrogers @ 2008-05-29 3:16 ` ahab 2008-05-29 10:31 ` Sebastian Hanigk 2008-05-30 7:26 ` [Ravenscar] " Niklas Holsti 2008-05-30 12:17 ` jimmaureenrogers 3 siblings, 1 reply; 19+ messages in thread From: ahab @ 2008-05-29 3:16 UTC (permalink / raw) Have the task immediately call a suspension object or a protected entry. You might want to read the Ravenscar Profile Users' Guide here: http://polaris.dit.upm.es/~ork/documents/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: run tasks on events 2008-05-29 3:16 ` ahab @ 2008-05-29 10:31 ` Sebastian Hanigk 2008-05-29 18:56 ` Anh Vo 0 siblings, 1 reply; 19+ messages in thread From: Sebastian Hanigk @ 2008-05-29 10:31 UTC (permalink / raw) ahab <ahabeger@gmail.com> writes: > Have the task immediately call a suspension object or a protected > entry. Hmm, this works only for one task if I'm not mistaken (a suspension object allows only one blocking call to Suspend_Until_True at the same time, a protected entry seems to have similar constraints). A solution would be a suspension object per task, but this is far from the elegance of HAL/S' signals. Sebastian ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: run tasks on events 2008-05-29 10:31 ` Sebastian Hanigk @ 2008-05-29 18:56 ` Anh Vo 2008-05-30 6:56 ` Sebastian Hanigk 0 siblings, 1 reply; 19+ messages in thread From: Anh Vo @ 2008-05-29 18:56 UTC (permalink / raw) On May 29, 3:31 am, Sebastian Hanigk <han...@in.tum.de> wrote: > ahab <ahabe...@gmail.com> writes: > > Have the task immediately call a suspension object or a protected > > entry. > > Hmm, this works only for one task if I'm not mistaken (a suspension > object allows only one blocking call to Suspend_Until_True at the same > time, a protected entry seems to have similar constraints). A solution > would be a suspension object per task, but this is far from the elegance > of HAL/S' signals. > > Sebastian It is not true. Protected entry, implemented in Transient Signals for example, can suspend/release multiple tasks. AV ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: run tasks on events 2008-05-29 18:56 ` Anh Vo @ 2008-05-30 6:56 ` Sebastian Hanigk 0 siblings, 0 replies; 19+ messages in thread From: Sebastian Hanigk @ 2008-05-30 6:56 UTC (permalink / raw) Anh Vo <anhvofrcaus@gmail.com> writes: > It is not true. Protected entry, implemented in Transient Signals for > example, can suspend/release multiple tasks. You're right, sorry, I should have perused the ARM beforehand. I have now created a protected type with a Boolean member, a procedure to set the Boolean and a protected entry with the Boolean as guard, the entry's body is empty. Inside the tasks' loops I'm calling the type's entry which suspends or activates the task depending on the Boolean flag. Is this a good or adequate solution or have I missed something critical? Best regards, Sebastian ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Ravenscar] run tasks on events 2008-05-28 19:14 [Ravenscar] run tasks on events Sebastian Hanigk 2008-05-28 23:47 ` jimmaureenrogers 2008-05-29 3:16 ` ahab @ 2008-05-30 7:26 ` Niklas Holsti 2008-05-30 8:57 ` Sebastian Hanigk 2008-05-30 12:17 ` jimmaureenrogers 3 siblings, 1 reply; 19+ messages in thread From: Niklas Holsti @ 2008-05-30 7:26 UTC (permalink / raw) Sebastian Hanigk wrote: > Hello, > > sorry if this is a stupid question, but as newcomer to Ada I've stumbled > over the following problem: having read a bit on HAL/S which has task > scheduling depending on signals and conditions, I'm a bit at loss how to > implement such functionality in Ada under the Ravenscar profile (no > dynamic task spawning). Note that Ravenscar has other restrictions, too, which means that some of the answers you got are not valid: jimmaureenrogers@worldnet.att.net wrote: > ... > You can create a task which suspends until the ascent/descent > phase. Simply have the task suspend on an accept statement. > The task will complete its execution upon execution of a > rendezvous associated with the accept statement. The Ravenscar profile forbids task entries and rendezvous, so the above is not possible. Ravenscar tasks can be controlled only by protected object entries and suspension objects from Ada.Synchronous_Task_Control. >> ahab <ahabe...@gmail.com> writes: >> >>> Have the task immediately call a suspension object or a >>> protected entry. Both methods work. > On May 29, 3:31 am, Sebastian Hanigk <han...@in.tum.de> wrote: >> ... >> Hmm, this works only for one task if I'm not mistaken (a >> suspension object allows only one blocking call to >> Suspend_Until_True at the same time... That's right, so you would need one suspension object per task, whether or not the Ravenscar profile is in effect. >> a protected entry seems to have similar constraints). This is true only under the Ravenscar profile, because of the Ravenscar restriction that Max_Entry_Queue_Length is 1. In unrestricted Ada, many tasks can be waiting on the same entry. Anh Vo wrote: > It is not true. Protected entry, implemented in Transient > Signals for example, can suspend/release multiple tasks. True in unrestricted Ada (an entry queue can hold many tasks), false under the Ravenscar profile (maximum one task waiting on an entry). If you use protected objects to trigger tasks, you need one object per task. Note that under the Ravenscar profile, one generally needs one protected object per (sporadic) task, anyway, to trigger that task when required. This protected object can easily be extended with a boolean control variable such that the entry triggers the task only in the appropriate modes or phases. On the other hand, personally I'm a bit skeptical about triggering certain tasks only in certain modes. I suspect that most systems could as well keep the same set of active tasks, and just make the tasks do different things in different modes, using plain old "if then else" in the task body. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Ravenscar] run tasks on events 2008-05-30 7:26 ` [Ravenscar] " Niklas Holsti @ 2008-05-30 8:57 ` Sebastian Hanigk 2008-05-30 10:47 ` Niklas Holsti 0 siblings, 1 reply; 19+ messages in thread From: Sebastian Hanigk @ 2008-05-30 8:57 UTC (permalink / raw) Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > Anh Vo wrote: >> It is not true. Protected entry, implemented in Transient >> Signals for example, can suspend/release multiple tasks. > > True in unrestricted Ada (an entry queue can hold many tasks), false > under the Ravenscar profile (maximum one task waiting on an entry). If > you use protected objects to trigger tasks, you need one object per > task. Argh. Seems I was too early in my reply to Anh Vo ... Shouldn't there be a constraint error? > Note that under the Ravenscar profile, one generally needs one > protected object per (sporadic) task, anyway, to trigger that task > when required. This protected object can easily be extended with a > boolean control variable such that the entry triggers the task only in > the appropriate modes or phases. I hadn't included the Profile pragma in all my source files, so I'm assuming that the successful test earlier on was due to not complying with the Ravenscar profile. Having put the pragma directives into the source code, now only one of the waiting tasks resumes/suspends. > On the other hand, personally I'm a bit skeptical about triggering > certain tasks only in certain modes. I suspect that most systems could > as well keep the same set of active tasks, and just make the tasks do > different things in different modes, using plain old "if then else" in > the task body. Well, I found the signaling/scheduling concept very elegant; now it seems my best bet would be a check inside each task's loop if the respective conditions evaluate to True, otherwise simply delay until the next period. Thank you for your help! Sebastian ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Ravenscar] run tasks on events 2008-05-30 8:57 ` Sebastian Hanigk @ 2008-05-30 10:47 ` Niklas Holsti 2008-05-30 11:17 ` Sebastian Hanigk 2008-05-30 11:59 ` stefan-lucks 0 siblings, 2 replies; 19+ messages in thread From: Niklas Holsti @ 2008-05-30 10:47 UTC (permalink / raw) Sebastian Hanigk wrote: > Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > > >>Anh Vo wrote: >> >>>It is not true. Protected entry, implemented in Transient >>>Signals for example, can suspend/release multiple tasks. >> >>True in unrestricted Ada (an entry queue can hold many tasks), false >>under the Ravenscar profile (maximum one task waiting on an entry). If >>you use protected objects to trigger tasks, you need one object per >>task. > > > Argh. Seems I was too early in my reply to Anh Vo ... > > Shouldn't there be a constraint error? Acccording to LRM D.7.19(1/2), violation of Max_Entry_Queue_Length raises Program_Error at the violating entry call. In unrestricted Ada, if an exception occurs in a task, and the task does not handle the exception, the task by default terminates silently when the exception propagates out of the task. If you want to know about exceptions in a task, you should put a last-chance, catch-all exception handler in the task body ("exception when others => ..."). Since the Ravenscar profile contains the restriction No_Task_Termination, by LRM D.7.15(1/2) it is implementation defined what happens when a Ravenscar task terminates due to an unhandled exception or for other reasons. It may be reported or signalled in some way, or not. > I hadn't included the Profile pragma in all my source files, so I'm > assuming that the successful test earlier on was due to not complying > with the Ravenscar profile. Having put the pragma directives into the > source code, now only one of the waiting tasks resumes/suspends. The Profile pragma is a "configuration" pragma. If you use Gnat, you should normally put configuration pragmas in a separate file called "gnat.adc", and Gnat will then include them in all compilations. See the GNAT User Guide; I haven't used such pragmas myself, so I'm not expert. > Well, I found the signaling/scheduling concept very elegant; now it > seems my best bet would be a check inside each task's loop if the > respective conditions evaluate to True, otherwise simply delay until the > next period. That is a good solution for periodic tasks, where the task is triggered by "delay until" and not by an event. Of course you will waste some processor time on unnecessary activations of the task. To avoid that, make the task suspend itself on a suspension object (a different object for each task) when the task has nothing to do. The "elegance" of this solution is subjective, of course, but I don't find it very ugly to have a different object for each task; it even makes it easier to select the subset of tasks that should become active. Note also that transitions between phases or modes must be planned and implemented carefully, perhaps over more than one task cycle, to avoid transients (both control transients and performance/deadline transients) during the transition. HTH, -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Ravenscar] run tasks on events 2008-05-30 10:47 ` Niklas Holsti @ 2008-05-30 11:17 ` Sebastian Hanigk 2008-05-30 15:24 ` Alex R. Mosteo 2008-05-30 11:59 ` stefan-lucks 1 sibling, 1 reply; 19+ messages in thread From: Sebastian Hanigk @ 2008-05-30 11:17 UTC (permalink / raw) Niklas Holsti <niklas.holsti@tidorum.invalid> writes: Hello! > Since the Ravenscar profile contains the restriction > No_Task_Termination, by LRM D.7.15(1/2) it is implementation defined > what happens when a Ravenscar task terminates due to an unhandled > exception or for other reasons. It may be reported or signalled in > some way, or not. I'm using GNAT 4.0.2 on Solaris 10 (AMD); it seems that my second test task has silently died. > [suspension objects per task] > > The "elegance" of this solution is subjective, of course, but I don't > find it very ugly to have a different object for each task; it even > makes it easier to select the subset of tasks that should become > active. I have to confess that I was rather enthralled with the simplicity of the signal/scheduler method ;-) The difference most likely is only the shift in responsibility: in HAL/S the programmer simply specifies when to activate tasks, in Ada I have to do the bookkeeping myself (but I do gain more flexibility). Thanks for your advice! Sebastian ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Ravenscar] run tasks on events 2008-05-30 11:17 ` Sebastian Hanigk @ 2008-05-30 15:24 ` Alex R. Mosteo 2008-05-30 15:35 ` Ed Falis 0 siblings, 1 reply; 19+ messages in thread From: Alex R. Mosteo @ 2008-05-30 15:24 UTC (permalink / raw) Sebastian Hanigk wrote: > Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > > Hello! > >> Since the Ravenscar profile contains the restriction >> No_Task_Termination, by LRM D.7.15(1/2) it is implementation defined >> what happens when a Ravenscar task terminates due to an unhandled >> exception or for other reasons. It may be reported or signalled in >> some way, or not. > > I'm using GNAT 4.0.2 on Solaris 10 (AMD); it seems that my second test > task has silently died. Look also at Ada.Task_Termination, although I don't know if it mix with ravenscar. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Ravenscar] run tasks on events 2008-05-30 15:24 ` Alex R. Mosteo @ 2008-05-30 15:35 ` Ed Falis 2008-05-30 18:02 ` Sebastian Hanigk 0 siblings, 1 reply; 19+ messages in thread From: Ed Falis @ 2008-05-30 15:35 UTC (permalink / raw) On Fri, 30 May 2008 11:24:22 -0400, Alex R. Mosteo <devnull@mailinator.com> wrote: > Look also at Ada.Task_Termination, although I don't know if it mix with > ravenscar. I may be mistaken, but I beleive the Ravenscar profile prohibits any units depending on Ada.Task_Termination. I would also recommend Burns and Wellings "Concurrent and Real Time Programming in Ada". It is extremely comprehensive. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Ravenscar] run tasks on events 2008-05-30 15:35 ` Ed Falis @ 2008-05-30 18:02 ` Sebastian Hanigk 2008-05-30 18:11 ` Ed Falis 0 siblings, 1 reply; 19+ messages in thread From: Sebastian Hanigk @ 2008-05-30 18:02 UTC (permalink / raw) "Ed Falis" <falis@verizon.net> writes: > I would also recommend Burns and Wellings "Concurrent and Real Time > Programming in Ada". It is extremely comprehensive. Which edition should I try to get on loan? Our library has only the 1985 edition (which will supposedly be a bit outdated) ... but there's always lending from a remote library :-) Sebastian ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Ravenscar] run tasks on events 2008-05-30 18:02 ` Sebastian Hanigk @ 2008-05-30 18:11 ` Ed Falis 0 siblings, 0 replies; 19+ messages in thread From: Ed Falis @ 2008-05-30 18:11 UTC (permalink / raw) On Fri, 30 May 2008 14:02:34 -0400, Sebastian Hanigk <hanigk@in.tum.de> wrote: > Which edition should I try to get on loan? Our library has only the 1985 > edition (which will supposedly be a bit outdated) ... but there's always > lending from a remote library I would definitely get the newest edition (2007). Much improved over the previous version because Ada 05 addresses issues that had with Ada 95. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Ravenscar] run tasks on events 2008-05-30 10:47 ` Niklas Holsti 2008-05-30 11:17 ` Sebastian Hanigk @ 2008-05-30 11:59 ` stefan-lucks 1 sibling, 0 replies; 19+ messages in thread From: stefan-lucks @ 2008-05-30 11:59 UTC (permalink / raw) On Fri, 30 May 2008, Niklas Holsti wrote: > In unrestricted Ada, if an exception occurs in a task, and the task does not > handle the exception, the task by default terminates silently when the > exception propagates out of the task. If you want to know about exceptions in > a task, you should put a last-chance, catch-all exception handler in the task > body ("exception when others => ..."). You don't need this in Ada 05 any more. You can define some callback procedures, to do something in the case of unhandled exceptions (and normal and abnormal termination as well, if you want to). The following is similar to an example in Barnes' book, except that the usage avoids race conditions: -------------------------------------------------------------------------- Package defined in <http://www.adaic.org/standards/05rm/html/RM-C-7-3.html>: with Ada.Task_Identification; with Ada.Exceptions; package Ada.Task_Termination is ... type Cause_Of_Termination is (Normal, Abnormal, Unhandled_Exception); type Termination_Handler is access protected procedure (Cause : in Cause_Of_Termination; T : in Ada.Task_Identification.Task_Id; X : in Ada.Exceptions.Exception_Occurrence); procedure Set_Dependents_Fallback_Handler(Handler: in Termination_Handler); ... end Ada.Task_Termination; -------------------------------------------------------------------------- Specification of Callback: protected End_Of is procedure World(C: Cause_Of_Termination; T: Task_ID; X: Exception_Occurrence); end End_Of; -------------------------------------------------------------------------- Implementation of Callback: procedure World(C: Cause_Of_Termination; T: Task_ID; X: Exception_Occurrence); begin case C is when Normal => null; when Abnormal => Put_Log("abnormal termination of Task" & Image(T)); when Unhandled_Exception => Put_Log("unhandled exception in Task" & Image(T)); Put_Log(Exception_Information(X)); end case; end World; -------------------------------------------------------------------------- Usage of callback (typically in main program / environment task): begin Set_Dependents_Fallback_Handler(End_Of.World); declare -- any task you want A_Bunch_Of_Tasks: array (0 .. 1023) of Some_Task_Type; Alice, Bob: Some_Other_Task_Type; begin ... -- Whenever any of our tasks terminates normally or abnormally or -- propagates an exception, End_Of.World is called. end; end; So long Stefan -- ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ Stefan dot Lucks at uni minus weimar dot de ------ I love the taste of Cryptanalysis in the morning! ------ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: run tasks on events 2008-05-28 19:14 [Ravenscar] run tasks on events Sebastian Hanigk ` (2 preceding siblings ...) 2008-05-30 7:26 ` [Ravenscar] " Niklas Holsti @ 2008-05-30 12:17 ` jimmaureenrogers 2008-05-30 18:59 ` Sebastian Hanigk 3 siblings, 1 reply; 19+ messages in thread From: jimmaureenrogers @ 2008-05-30 12:17 UTC (permalink / raw) On May 28, 1:14 pm, Sebastian Hanigk <han...@in.tum.de> wrote: > Hello, > > sorry if this is a stupid question, but as newcomer to Ada I've stumbled > over the following problem: having read a bit on HAL/S which has task > scheduling depending on signals and conditions, I'm a bit at loss how to > implement such functionality in Ada under the Ravenscar profile (no > dynamic task spawning). > > The example from the HAL/S user guide were tasks running e.g. only in > the free-fall or ascent/descent phase, started and terminated by > signals. > > Thanks for any help or pointers! > > Sebastian I am curious why you are comparing unrestrained HAL/S with a restrained Ada profile. You can certainly design many interesting shared resource design patterns using unrestrained Ada. You might find http://home.att.net/~jimmaureenrogers/Shared_Resource_Design_Patterns.html interesting to consider. Jim Rogers ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: run tasks on events 2008-05-30 12:17 ` jimmaureenrogers @ 2008-05-30 18:59 ` Sebastian Hanigk 2008-06-02 10:32 ` Alex R. Mosteo 0 siblings, 1 reply; 19+ messages in thread From: Sebastian Hanigk @ 2008-05-30 18:59 UTC (permalink / raw) "jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net> writes: > I am curious why you are comparing unrestrained HAL/S with a > restrained Ada profile. You can certainly design many interesting > shared resource design patterns using unrestrained Ada. Mostly out of curiosity at the moment. I've stumbled over some shuttle documents (<http://klabs.org/DEI/Processor/shuttle/index.htm>), read "Programming in HAL/S" and found a few interesting concepts which started the endeavour to find similar ones in Ada. Why Ravenscar? My job will in the foreseeable future provide me with the opportunity for involvement in the writing of (near-)real-time control software and I think it will be beneficial to work with a restricted language subset (Ravenscar + SPARK eventually) from a validation perspective. > You might find > http://home.att.net/~jimmaureenrogers/Shared_Resource_Design_Patterns.html > interesting to consider. Great, I'll start reading after supper! Sebastian ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: run tasks on events 2008-05-30 18:59 ` Sebastian Hanigk @ 2008-06-02 10:32 ` Alex R. Mosteo 0 siblings, 0 replies; 19+ messages in thread From: Alex R. Mosteo @ 2008-06-02 10:32 UTC (permalink / raw) Sebastian Hanigk wrote: > "jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net> > writes: > >> I am curious why you are comparing unrestrained HAL/S with a >> restrained Ada profile. You can certainly design many interesting >> shared resource design patterns using unrestrained Ada. > > Mostly out of curiosity at the moment. I've stumbled over some shuttle > documents (<http://klabs.org/DEI/Processor/shuttle/index.htm>), read > "Programming in HAL/S" and found a few interesting concepts which > started the endeavour to find similar ones in Ada. > > Why Ravenscar? My job will in the foreseeable future provide me with the At least one reason I've heard sometimes is to simplify the runtime, which may be useful for validation, writing for simple hardware, etc. However, I expect you'll get more informative replies. > opportunity for involvement in the writing of (near-)real-time control > software and I think it will be beneficial to work with a restricted > language subset (Ravenscar + SPARK eventually) from a validation > perspective. > >> You might find >> http://home.att.net/~jimmaureenrogers/Shared_Resource_Design_Patterns.html >> interesting to consider. > > Great, I'll start reading after supper! > > > Sebastian ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2008-06-02 10:32 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-05-28 19:14 [Ravenscar] run tasks on events Sebastian Hanigk 2008-05-28 23:47 ` jimmaureenrogers 2008-05-29 10:35 ` Sebastian Hanigk 2008-05-29 3:16 ` ahab 2008-05-29 10:31 ` Sebastian Hanigk 2008-05-29 18:56 ` Anh Vo 2008-05-30 6:56 ` Sebastian Hanigk 2008-05-30 7:26 ` [Ravenscar] " Niklas Holsti 2008-05-30 8:57 ` Sebastian Hanigk 2008-05-30 10:47 ` Niklas Holsti 2008-05-30 11:17 ` Sebastian Hanigk 2008-05-30 15:24 ` Alex R. Mosteo 2008-05-30 15:35 ` Ed Falis 2008-05-30 18:02 ` Sebastian Hanigk 2008-05-30 18:11 ` Ed Falis 2008-05-30 11:59 ` stefan-lucks 2008-05-30 12:17 ` jimmaureenrogers 2008-05-30 18:59 ` Sebastian Hanigk 2008-06-02 10:32 ` Alex R. Mosteo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox