Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Advanced Topics in Object Technology Bertrand Meyer.

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Advanced Topics in Object Technology Bertrand Meyer

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Lecture 21: Concurrency and real-time systems By Volkan Arslan (Piotr Nienaltowski)

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Overview  Goal  Basics of the SCOOP model  Architecture and implementation of SCOOP  Examples  Basics of the real-time systems  Timing and real-time extensions  Conclusion and future work

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Goal Extend a pure, strongly typed, object-oriented language (Eiffel, …) with  a simple, general and powerful concurrency and distribution model (  SCOOP)  and extend SCOOP to support real-time programming

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 The SCOOP model  Simple Concurrent Object-Oriented Programming  High-level concurrency mechanism  Full use of inheritance and other object-oriented techniques  Applicable to many physical setups: multiprocessing, multithreading, distributed execution, etc.

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Object-oriented computation To perform a computation is  to use certain processors  to apply certain actions  to certain objects.

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 What makes an application concurrent? Processor: autonomous thread of control supporting sequential execution of instructions on one or more objects Can be implemented as:  Computer CPU  Process  Thread  AppDomain (.NET) … Mapping of processors to computational resources through Concurrency Control File (CCF)

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Feature call (synchronous call)  Fundamental scheme of O-O computation: feature call x.f (a)  x: CLASS_X

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Separate feature call (asynchronous call)  Fundamental scheme of O-O computation: feature call x.f (a)  x: separate CLASS_X

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Feature call (synchronous call)  Fundamental scheme of O-O computation: feature call x.f (a)  x: CLASS_X

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Separate feature call (asynchronous call)  Fundamental scheme of O-O computation: feature call x.f (a)  x: separate CLASS_X

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Access control policy  Target of a separate call must be formal argument of enclosing routine: store (b: separate BUFFER [G]; value: G) is -- Store value into b. do b.put (value) end  To obtain exclusive access to a separate object, use it as argument of call: my_buffer: separate BUFFER [INTEGER] create my_buffer store (my_buffer, 10)

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 From preconditions to wait-conditions Contracts in Eiffel store (b: BUFFER [G]; value: G) is -- Store value into b. require not b.is_full value /= Void do b.put (value) ensure not b.is_empty end... store (my_buffer, 10)  If b is separate, precondition becomes wait condition (instead of correctness condition)

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 From preconditions to wait-conditions Contracts in Eiffel store (b: separate BUFFER [G]; value: G) is -- Store value into b. require not b.is_full value /= Void do b.put (value) ensure not b.is_empty end... store (my_buffer, 10)  If b is separate, precondition becomes wait condition (instead of correctness condition)

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Synchronization  No special mechanism needed for client to resynchronize with supplier after separate call.  The client will wait only when it needs to: x.fx.f x.g (a) y.fy.f … value := x.some_query

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Synchronization  No special mechanism needed for client to resynchronize with supplier after separate call.  The client will wait only when it needs to: x.f x.g (a) y.f … value := x.some_query

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Synchronization  No special mechanism needed for client to resynchronize with supplier after separate call.  The client will wait only when it needs to: x.f x.g (a) y.f … value := x.some_query … if value > 10 then … end

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Synchronization  No special mechanism needed for client to resynchronize with supplier after separate call.  The client will wait only when it needs to: x.fx.f x.g (a) y.fy.f … value := x.some_query … if value > 10 then … end  This mechanism is called wait by necessity.

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 CCF – Mapping of processors to physical resources  Location of processors need not be specified at compile time  On the fly specification with Concurrency Control File (CCF) creation system "goethe" (4): "c:\prog\appl1\appl1.exe" "beethoven" (2): "c:\prog\appl2\appl2.dll" "Current" (5): "c:\prog\appl3\appl3.dll" end external Database_handler: "daimler_benz" port 9000 ATM_handler: "duerer" port 8001 end default port: 8001; instance: 10 end

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 CCF – Mapping of processors to physical resources  Location of processors need not be specified at compile time  On the fly specification with Concurrency Control File (CCF) creation system "Current": "c:\prog\appl1\appl1.exe" end external Database_handler: "daimler_benz" port 9000 ATM_handler: "duerer" port 8001 end default port: 8001; instance: 10 end

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Two-level architecture of SCOOP  SCOOP can be implemented in several environments  Microsoft.NET is our current platform SCOOP platform-independent.NET Compact Framework POSIX Threads …

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Implementation  SCOOPLI for.NET and others  Library implementation of SCOOP in its original version  Uses Remoting and Threading capabilities of.NET  Uses Threading capabilities of the.NET CF on the RTOS Windows CE.NET (and/or other RTOS: VxWorks, etc.)

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Example: Bounded buffers separate class BOUNDED_BUFFER [G] inherit BOUNDED_QUEUE [G] end

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Example: Bounded buffers indexing description: "Encapsulation of access to bounded buffers" class BUFFER_ACCESS [G] feature put (q: BOUNDED_BUFFER [G]; x: G) is -- Insert x into q, waiting if necessary until there is room. require not q.full do q.put (x) ensure not q.empty end

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Example: Bounded buffers remove (q: BOUNDED_BUFFER [G]) is -- Remove an element from q, waiting if necessary -- until there is such an element require not q.empty do q.remove ensure not q.full end item (q: BOUNDED_BUFFER [G]): G is -- Oldest element not yet consumed require not q.empty do Result := q.remove end end -- class BUFFER_ACCESS [G]

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Example: Bounded buffers Usage of bounded buffers my_buffer_access : BUFFER_ACCESS [INTEGER] my_bounded_buffer : BOUNDED_BUFFER [INTEGER] create my_buffer_access create my_bounded_buffer my_buffer_access.put (my_bounded_buffer, 25) my_buffer_access.put (my_bounded_buffer, 50) my_result := my_buffer_acces.item (my_bounded_buffer)

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Example: Dining philosophers separate class PHILOSOPHER inherit GENERAL_PHILOSOPHER PROCESS rename setup as getup undefine getup end feature {BUTLER} step is -- Perform a philosopher’s tasks. do think eat (left, right) end eat (l, r: separate FORK) is -- Eat, having grabbed l and r. do … end end -- class PHILOSOPHER

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Class PROCESS indexing description: "The most general notion of process" deferred class PROCESS feature -- Status report over: BOOLEAN is -- Must execution terminate now? deferred end feature -- Basic operations setup is -- Prepare to execute process operations (default: nothing). do end step is -- Execute basic process operations. deferred end

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Class PROCESS (cont.) wrapup is -- Execute termination operations (default: nothing). do end feature -- Process behavior live is -- Perform process lifecycle. do from setup until over loop step end wrapup end end -- class PROCESS

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Class GENERAL_PHILOSOPHER class GENERAL_PHILOSOPHER create make feature -- Initialization make (l, r: separate FORK) is -- Define l as left and r as right forks. do left := l right := r end feature {NONE} -- Implementation left: separate FORK right: separate FORK

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Class GENERAL_PHILOSOPHER (cont.) getup is -- Take any necessary initialization action. do end think is -- Any appropriate action or lack thereof do end end -- class GENERAL_PHILOSOPHER class FORK end

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Class BUTLER class BUTLER create make feature count: INTEGER -- The number of both philosophers and forks launch is -- Start a full session. local i: INTEGER do from i := 1 until i > count loop launch_one (participants @ i) i := i + 1 end

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Class BUTLER (cont.) feature -- {NONE} launch_one (p: PHILOSOPHER) is -- Let one philosopher start his actual life. do p.live end participants: ARRAY [PHILOSOPHER] cutlery: ARRAY [FORK] feature {NONE} -- Initialization make (n: INTEGER) is -- Initialize a session with n philosophers. require n >= 0 do count := n create participants.make (1, count) create cutlery.make (1, count) make_philosophers launch ensure count = n end

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Class BUTLER (cont.) make_philosophers is -- Set up philosophers. local i: INTEGER p: PHILOSOPHER left, right: separate FORK do from i := 1 until i > count loop left := cutlery @ i right := cutlery @ ((i \\ count) + 1) create p.make (left, right) participants.put (p, i) i := i + 1 end invariant count >= 0 participants.count = count cutlery.count = count end -- class BUTLER

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Definition: Real-time system Real-time system (Young, 1982): Any information processing activity or system which has to respond to externally generated input stimuli within a finite and specified period.  The correctness of a real-time system depends not only on the logical result of the computation, but also on the time at which the results are produced...  a correct but a late response is as bad as a wrong response...

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Hard and soft real-time systems  Hard real-time Systems where it is absolutely imperative that responses occur within the required deadline. E.g. flight control systems, …  Soft real-time Systems where deadlines are important but which will still function correctly if deadlines are occasionally missed. E.g. data acquisition system, … A single real-time system may have both hard and soft real-time subsystems

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Definition: Embedded system Embedded system: The computer is an information processing component within (embedded in) a larger engineering system. (e.g. washing machine, process control computer, ABS ― Anti Blocking System in vehicles,...)

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Characteristics of real-time systems  Large and complex (up to 20 million lines of code estimated for the Space Station Freedom)  Concurrent control of separate system components  Facilities to interact with special purpose hardware  Extreme reliable and safe  Guaranteed response times

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Components of a real-time system  Hardware (CPU, sensors, ADC, DAC, …)  Real-time OS (e.g VxWorks, QNX, Windows CE.NET, …)  Real-time application and real-time runtime system (e.g. Ada, Real-Time Java, C with Real-Time Posix and hopefully soon Real-Time SCOOP )

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 A simple embedded and real-time example

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Real-Time Facilities  Notion of time  Clocks  Delays  Timeouts  Temporal scopes

Chair of Software Engineering 47 Notion of time  Linearity:  Transitivity:  Irreflexibility:  Density:  The passage of time is equated with a real line.

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Access to a Clock  Direct access to the environment's time frame (e.g. transmitters for UTC = Universal Time Coordinated, UTC service of GPS)  Using an internal hardware clock that gives an adequate approximation to the passage of time in the environment

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Clocks in Real-Time Java  java.lang.System.currentTimeMillis returns the number of milliseconds since 1/1/1970 GMT and is used by java.util.Date  Real-time Java adds real-time clocks with high resolution time types

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 RT Java Time Types (1) public abstract class HighResolutionTime implements java.lang.Comparable { public abstract AbsoluteTime absolute(Clock clock, AbsoluteTime destination);... public boolean equals(HighResolutionTime time); public final long getMilliseconds(); public final int getNanoseconds(); public void set(HighResolutionTime time); public void set(long millis); public void set(long millis, int nanos); }

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 RT Java Time Types (2) public class AbsoluteTime extends HighResolutionTime { // various constructor methods including public AbsoluteTime(AbsoluteTime T); public AbsoluteTime(long millis, int nanos); public AbsoluteTime absolute(Clock clock, AbsoluteTime dest); public AbsoluteTime add(long millis, int nanos); public final AbsoluteTime add(RelativeTime time);... public final RelativeTime subtract(AbsoluteTime time); public final AbsoluteTime subtract(RelativeTime time); }

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 RT Java Time Types (3) public class RelativeTime extends HighResolutionTime { // various constructor methods including public RelativeTime(long millis, int nanos); public RelativeTime(RelativeTime time); public AbsoluteTime absolute(Clock clock, AbsoluteTime destination); public RelativeTime add(long millis, int nanos); public final RelativeTime add(RelativeTime time); public void addInterarrivalTo(AbsoluteTime destination); public final RelativeTime subtract(RelativeTime time);... } public class RationalTime extends RelativeTime {...}

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 RT Java: Clock Class public abstract class Clock { public Clock(); public static Clock getRealtimeClock(); public abstract RelativeTime getResolution(); public AbsoluteTime getTime(); public abstract void getTime(AbsoluteTime time); public abstract void setResolution(RelativeTime resolution); }

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 RT Java: Measuring Time { AbsoluteTime oldTime, newTime; RelativeTime interval; Clock clock = Clock.getRealtimeClock(); oldTime = clock.getTime(); // other computations newTime = clock.getTime(); interval = newTime.subtract(oldTime); }

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Delaying a Process (Thread)  The execution of a process (thread) must be sometimes delayed either for a relative period of time or until some time in the future  Relative delays Start := Clock; -- from calendar loop exit when (Clock - Start) > 10.0; end loop;  Busy-waits are not efficient, therefore most languages and operating systems provide some form of delay primitive  In Ada, this is a delay statement delay 10.0;  In POSIX: sleep and nanosleep  Java: sleep; RT Java provides a high resolution sleep

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Delays Time specified by program Granularity difference between clock and delay Interrupts disabled Process runnable here but not executable Process executing Time

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Absolute Delays  In Ada Start := Clock; First_action; delay 10.0 - (Clock - Start); Second_action;  Unfortunately, this might not achieve the desired result, therefore we use: Start := Clock; First_action; delay until Start + 10.0; Second_action;  As with delay, delay until is accurate only in its lower bound  RT Java - sleep can be relative or absolute  POSIX requires use of an absolute timer and signal

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Drifts  The time overrun associated with both relative and absolute delays is called the local drift and it cannot be eliminated  It is possible, however, to eliminate the cumulative drift that could arise if local drifts were allowed to superimpose

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Periodic Activity task body T is Interval : constant Duration := 5.0; Next_Time : Time; begin Next_Time := Clock + Interval; loop Action; delay until Next_Time; Next_Time := Next_Time + Interval; end loop; end T; Will run on average every 5 seconds local drift only If Action takes 6 seconds, the delay statement will have no effect

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Control Example in Ada (1) with Ada.Real_Time; use Ada.Real_Time; with Data_Types; use Data_Types; with IO; use IO; with Control_Procedures; use Control_Procedures; procedure Controller is task Temp_Controller; task Pressure_Controller ;

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Control Example in Ada (2) task body Temp_Controller is TR : Temp_Reading; HS : Heater_Setting; Next : Time; Interval : Time_Span := Milliseconds(200); begin Next := Clock; -- start time loop Read(TR); Temp_Convert(TR,HS); Write(HS); Next := Next + Interval; delay until Next; end loop; end Temp_Controller;

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Control Example in Ada (3) task body Pressure_Controller is PR : Pressure_Reading; PS : Pressure_Setting; Next : Time; Interval : Time_Span := Milliseconds(150); begin Next := Clock; -- start time loop Read(PR); Pressure_Convert(PR,PS); Write(PS); Next := Next + Interval; delay until Next; end loop; end Pressure_Controller; begin null; end Controller;

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Timeouts on Actions select delay 0.1; then abort -- action end select;  If the action takes too long (more than 100 ms), the action will be aborted  Java supports timeouts through the class Timed.

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Temporal Scopes (1)  Temporal scope: Collection of statements with an associated timing constraint  Deadline — the time by which the execution of a TS must be finished  Minimum delay — the minimum amount of time that must elapse before the start of execution of a TS  Maximum delay — the maximum amount of time that can elapse before the start of execution of a TS  Maximum execution time — of a TS  Maximum elapse time — of a TS Temporal scopes with combinations of these attributes are also possible

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Temporal Scopes (2) Now Time Deadline a b c Minimum delay Maximum delay Maximum elapse time Units of execution Maximum execution time = a + b +c

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Specifying Processes and TS process periodic_P;... begin loop IDLE start of temporal scope... end of temporal scope end; Time constraints:  maximum and/or minimum times for IDLE  At the end of the temporal scope a deadline must be met

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Deadline The deadline can itself be expressed in terms of either  absolute time  execution time since the start of the temporal scope, or  elapsed time since the start of the temporal scope.

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Aperiodic Processes process aperiodic_P;... begin loop wait for interrupt start of temporal scope... end of temporal scope end;

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 SCOOP for real-time systems  Timing assertions  Maximal (and minimal) execution time  Timeouts on actions  Periodic and aperiodic activities  Possibility to execute the request of a VIP client while stopping the execution of the current client  Duels  Priorities

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Timing in sequential programming In library class TIMING_ASSERTION: time_now: TIME -- The current time now. min_time_duration: TIME_DURATION -- Minimal time duration of a feature max_time_duration: TIME_DURATION -- Maximal time duration of a feature In application class SUPPLIER (inherits TIMING_ASSERTION): create min_time_duration.make_by_fine_seconds (1.0) create max_time_duration.make_by_fine_seconds (3.0)

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Timing in sequential programming (cont.) f (a_time_started: TIME; an_i: INTEGER): INTEGER is require a_time_started_not_void: a_time_started /= Void local i: INTEGER do from i := 0 until i = an_i loop Result := Result + i i := i + 1 end create time_now.make_now ensure minimal_execution_time: (time_now - a_time_started).duration > min_time_duration maximal_execution_time: (time_now - a_time_started).duration < max_time_duration end

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Timing in sequential programming (cont.) In client class CLIENT: s: SUPPLIER time_now: TIME res: INTEGER create s create time_now.make_now res := s.f (time_now, 1000000)

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Timing in sequential programming (cont.) f (a_time_started: TIME; an_i: INTEGER): INTEGER is require a_time_started_not_void: a_time_started /= Void local i: INTEGER do from i := 0 until i = an_i loop Result := Result + i i := i + 1 end create time_now.make_now ensure minimal_execution_time: (time_now - a_time_started).duration > min_time_duration maximal_execution_time: (time_now - a_time_started).duration < max_time_duration end

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Timing assertions Specifying temporal scopes with the assertion mechanism of Eiffel (has consequences to the scheduling mechanism)  Maximal (and minimal?) execution time of a feature call x.f (a, b)  f (a: A, b: separate B) is require a /= Void not b.empty ensure -- maximal execution time of f is 100 ms maximal_execution_time (100) -- minimal execution time of f is 50 ms minimal_execution_time (50) end

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Timing assertions Timeout on actions  f (a: A, b: separate B) is require a /= Void not b.empty do -- action b.g (h) must not take longer than 20 ms check timeout: timeout (20) b.g (h) end ensure -- maximal execution time of f is 100 ms maximum_execution_time (100) -- minimal execution time of f is 50 ms minimum_execution_time (50) end

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Timing assertions Specification of periodic (and aperiodic) activities  f (a: A, b: separate B) is require a /= Void not b.empty -- activated at absolute time between 4000 and 4500 activation_time > 4000 and activation_time < 4500 ensure -- periodicity is 500 ms periodicity (500) end

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Duels Can we snatch a shared object from its current holder?  holder executes holder.r (b)where b is separate  Then another object challenger executes challenger.s (c) where c, also separate, is attached to the same object as the holder‘s b  Normally, the challenger will wait until the call to r is over.  What if the challenger is impatient?

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Duels Use library features from class CONCURRENCY:  Request immediate service: immediate_service  Accept immediate service: yield Challenger → ↓ Holder normal_serviceimmediate_service retain Challenger waitsException in challenger yield Challenger waitsException in holder; serve challenger

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Extending duels with priorities Tuning the duel mechanism:  holder.set_priority (50)  challenger.set_priority (100)  holder.yield  challenger.immediate_service If the priority of the challenger is bigger than the priority of the holder (challenger.priority > holder.priority):  holder will get an exception  challenger will be served.

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Conclusion SCOOP model is simple yet powerful  Full concurrency  Full use of object-oriented techniques  One keyword separate  Based on Design by Contract™  Several platforms and architectures (multiprocessing, multithreading, distributed execution, etc).

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Future work  Extension of access control policy  multiple locking of separate objects based on the concept of pure functions  Instruction-level parallelism  Deadlock prevention  Extending SCOOP for real-time systems  adding priorities to the duel mechanism  specifying temporal scopes with the assertion mechanism  SCOOP can be used for persistence  with the STORABLE class mechanism and separate DATABASE

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 References  http://se.inf.ethz.ch/people/nienaltowski http://se.inf.ethz.ch/people/nienaltowski  http://se.inf.ethz.ch/people/arslan http://se.inf.ethz.ch/people/arslan  http://se.inf.ethz.ch/projects (Concurrency, distribution,...) http://se.inf.ethz.ch/projects  Nienaltowski P., Arslan V., Meyer B.: SCOOP: Concurrent Programming Made Easy, in process of submission  Simon D., An Embedded Software Primer, 3rd printing, Addison-Wesley, 2000  Burns A., Wellings A., Real-Time Systems and Programming Languages, 3rd edition, Addison-Wesley, 2001

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 End of lecture 21

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Advanced Topics in Object Technology Bertrand Meyer.

Similar presentations

Presentation on theme: "Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Advanced Topics in Object Technology Bertrand Meyer."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Advanced Topics in Object Technology Bertrand Meyer.

Similar presentations

Presentation on theme: "Chair of Software Engineering ATOT - Lecture 21, 16 June 2003 Advanced Topics in Object Technology Bertrand Meyer."— Presentation transcript:

Similar presentations

About project

Feedback