Sie sind auf Seite 1von 21

Simple Concurrent Object-Oriented

Programming

Nati Fuks

Department of Computer Science, York University


SCOOP Outline

 SCOOP Introduction

 Generator

 SCOOP vs Java

 PRODUCER-CONSUMER example

 SCOOP Semantics

 Mapping from SCOOP to Eiffel+THREADs

Department of Computer Science, York University


Concurrency

 Concurrent programming is difficult


 e.g. Java Memory Flaw circa 1999
 A variety of mechanisms must be mastered
 Thread class, synchronize, wait, notify,
mutexes, monitor, critical regions
 Problems such as deadlock, safety and liveness
properties, inheritance anomaly

Department of Computer Science, York University


SCOOP
A single new keyword (separate) provides for a full-
fledged concurrency mechanism !!!

SCOOP platform-independent

.NET
Eiffel + Framework POSIX …
Threads

Department of Computer Science, York University


SCOOP

SCOOP: Simple Concurrent Object-Oriented


Programming. Defined by Bertrand Meyer in OOSC
in 1997
Implementations:

1. Compton. Changes in the open source SmallEiffel


compiler

2. This work

3. SCOOP in the .NET framework

Department of Computer Science, York University


SCOOP Generator

Why SCOOP Generator?


Object-Oriented Design

Design By Contract

Simple and intuitive concurrency model of SCOOP

What do we achieve?
Concurrent programs using SCOOP

Department of Computer Science, York University


SCOOP Generator

 Eiffel SCOOP -> Eiffel + THREAD

 Standard Eiffel code (mutexes and THREADs)


 Eiffel Studio 5.4

Advantages
 Pure Eiffel
 Independence
 Target code is cross-platform

Disadvantage – Debugging on a target code

Department of Computer Science, York University


Producer-Consumer Java Solution

Department of Computer Science, York University


Producer-Consumer SCOOP Solution

- same behaviour as the Java solution

- only one extra keyword separate is used (||)

- uses contracts with all the benefits of DbC

Department of Computer Science, York University


ROOT_CLASS

class ROOT_CLASS creation


make
feature

b: separate BUFFER
p: PRODUCER -- declared separate
c: CONSUMER -- declared separate

make is
-- Creation procedure.
do
create b.make
create p.make(b)
create c.make(b)
end
end

Department of Computer Science, York University


Bounded BUFFER

class BUFFER creation


make
feature

put (x:INTEGER) is
require count <= 3
do q.put(x)
ensure count = old count + 1 and q.has (x)
end

remove is
require count > 0
do q.remove
ensure count = old count - 1
end

Department of Computer Science, York University


PRODUCER

separate class PRODUCER creation


make
feature
buffer: separate BUFFER

make (b: separate BUFFER) is do …keep_producing … end

keep_producing is do … produce(buffer,i) … end

produce (b : separate BUFFER; i:INTEGER) is


require b.count <= 2
do b.put(i)
ensure b.has(i)
end
end

Department of Computer Science, York University


CONSUMER

separate class CONSUMER creation


make
feature
buffer: separate BUFFER

make (b: separate BUFFER) is do …keep_consuming… end

keep_consuming is do …consume(buffer)… end

consume (b: separate BUFFER) is


require b.count > 0
do b.remove
ensure b.count = old b.count - 1
end

end

Department of Computer Science, York University


Synchronization in SCOOP
A call to the routine produce with a separate will block until:

(a) the producer gets sole access to the buffer

(b) the buffer must not be full as indicated in the


precondition

Department of Computer Science, York University


Preconditions in SCOOP

if not buffer.full then


buffer.put(value)

produce (b: separate BUFFER; i: INTEGER) is


require
b.count <= 2
i >= 0
do
b.put (i)
end

Department of Computer Science, York University


Mapping to Eiffel + THREAD
separate class class ROOT_CLASS inherit
ROOT_CLASS THREAD_CONTROL

feature feature
request_pended: INTEGER_REF
requests_pended_mutex:MUTEX

b:separate BUFFER b:BUFFER


b_mutex: MUTEX
p:PRODUCER p:PRODUCER

Department of Computer Science, York University


Mapping to Eiffel 2
make is
make is
do
do
requests_pended := 1

b_mutex.lock
create b.make create b.make
b_mutex.unlock

Department of Computer Science, York University


Mapping to Eiffel 3

create p.make (b) create p.make (b, b_mutex,


requests_pended,
requests_pended_mutex)

p.launch

set_feature_to_do ([Current,
"KEEP_PRODUCING_ROUTINE"])

Department of Computer Science, York University


Mapping to Eiffel 4
create c.make (b) same as p.make…

requests_pended_mutex.lock
requests_pended.copy
(requests_pended-1)

requests_pended_mutex.unlock

join_all
end end
Department of Computer Science, York University
Contributions

 Analysis of Meyer’s SCOOP with a view to


implementation – semantics of SCOOP via
Compton’s subsystems
 Based on the semantics of SCOOP – provided a
mapping from SCOOP to Eiffel + Threads.
 Generator parses SCOOP programs, flags syntax
errors and automatically translates to portable
executable code based on the mapping.
 First full implementation of SCOOP
 contracts
 routine calls with multiple separate objects

Department of Computer Science, York University


Thank You

Department of Computer Science, York University

Das könnte Ihnen auch gefallen