Emerald et oo spr k for distribuerte applikasjoner review concurrency mobility
This presentation is the property of its rightful owner.
Sponsored Links
1 / 46

Emerald - et OO-språk for distribuerte applikasjoner Review – Concurrency - Mobility PowerPoint PPT Presentation


  • 86 Views
  • Uploaded on
  • Presentation posted in: General

Emerald - et OO-språk for distribuerte applikasjoner Review – Concurrency - Mobility. Eric Jul OMS Professor II . Emerald Review. We’ll start with a review of Emerald from the first lecture series (F1): Everything is an object Algol-60/Simula/Smalltalk heritage Object constructors

Download Presentation

Emerald - et OO-språk for distribuerte applikasjoner Review – Concurrency - Mobility

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Emerald et oo spr k for distribuerte applikasjoner review concurrency mobility

Emerald - et OO-språk for distribuerteapplikasjonerReview – Concurrency - Mobility

Eric Jul

OMS

Professor II


Emerald review

Emerald Review

We’ll start with a review of Emerald from the first lecture series (F1):

  • Everything is an object

  • Algol-60/Simula/Smalltalk heritage

  • Object constructors

  • Conformity based type system – think interfaces (e.g., as in Java)


People

People


Main contributions

Main Contributions

  • Distribution: Mobile objects (Eric/Hank)

    Anyobjectcanmove at any time. Fullon-the-fly

    • objectmobility

    • threadmobility

    • heterogeneousmobility

  • Conformitybased type system (Norm/Andrew)

    Type system basedonconformityprinciple

    Well-definedsemantics (e.g., NIL makessense!)

  • Clean OO language (betterthansuccesors?) including uniform object model


  • What does it look like

    What does it look like?

    • In a nutshell: Java with an Algol-like syntax

    • Heavily inspired by Algol/Simula and Smalltalk

    • ”Clean” OO language – ”everything” is an object: data, integers, strings, arrays, classes, types as in Smalltalk

    • Language constructs are NOT objects – for compilability and speed

    • No pointers: just object & object references


    Classless object construction

    ClasslessObject Construction

    Objectconstructors:

    objectseqno

    var prev: Integer = 0

    Integer operation getSeqNo[]

    prev <- prev +1

    returnprev

    end getSeqno

    end seqno

    The above is an executableexpression!


    Object constructors

    Object Constructors

    • Execution results in a new object

    • Execute again – and get yet another object

    • No class!

      Want classes?


    An object that is a class

    An Objectthat is a Class

    objectseqnoclass

    operation create[]

    return

    objectseqno

    var prev: Integer = 0

    Integer operation getSeqNo[]

    prev <- prev +1

    returnprev

    end getSeqno

    end seqno

    end create

    end seqnoclass


    Class done by syntatic sugaring

    Class done by SyntaticSugaring

    The followingturnsinto the previous double objectconstructor:

    classseqno

    var prev: Integer = 0

    Integer operation getSeqNo[]

    prev <- prev +1

    returnprev

    end getSeqno

    end seqno


    Types

    Types

    Types are abstract descriptions of the operations required of an object (think: Java Interfaces – they are close to identical to types in Emerald).

    Collection of operation signatures.

    Signature is name & types of each parameter


    What is conformity

    type BankAccount

    operation deposit[Integer]

    operation withdraw[Integer] ->[Integer]

    functionfetchBalance[] -> [Integer]

    end BankAccount

    type DepositOnlyBankAccount

    functionfetchBalance[] -> [Integer]

    operation deposit[Integer]

    end DepositOnlyBankAccount

    Conformityobject-to-type

    and type-to-type

    BankAccount conforms to DepositOnlyBankAccount because it support all the required operations – and the parameters also conform

    What is conformity?


    Conformity informally

    Conformity informally

    An object is said to conform to a type, if

    • It has the operations specified by the type

    • For each operation in the type:

      • The number of parameters is the same in the object as in the type

      • Each input parameter of the object conforms to the corresponding param of the type

      • Each output parameter of the type conforms to the corresponding param of the object (contra variant)


    Conformity between types

    Conformity between types

    Conformity is a mathematicalrelationship

    If T is to conform to S:

    • T must have all the operations required by S

    • For each operation in T the corresponding operation in S:

      • in-parameters must conform

      • out-parameters must conformin oppositeorder

        Contravariance: not in Simula nor Eiffel

        necessary to makesemanticsense of programs


    Conformity details

    Conformity details

    • Conformity is implicit

    • No ”implements” as in Java

    • Operation namesimportant

    • Parameter names do not matter, just their type

    • Aritymatters: foo(char) different from foo(char, float)


    Conformity more formally

    Conformity more formally

    NOT IMPORTANT HERE


    Lattice of types

    Lattice of types

    • Types form a lattice

    • Top is

      type Any

      end Any

    • Bottom is Noone(it has ALL operations”)

    • NILconforms to Noone

    • NILcanthusbeassigned to any variable! (Read ”MuchAdoAboutNIL.)


    Array

    Array

    • Just an object

    • Supports “of” which returns an object

    • Array.of[Integer]

    • This is a type (!)

    • But it is also an object – that supports create (!)

    • Creates an EMPTY array.

    • Addupper, addlower


    Today f2

    TODAY (F2)

    • Process concept (Emerald process = thread)

    • Synchronization using Monitors


    Process concept

    Process Concept

    A process is a thread of execution.

    Every object can have ONE process.

    Process section in object constructor


    Process section

    Process section

    object A

    initially

    … initializestuff

    end initially

    process

    … do something

    end process

    end A


    Process execution

    Process execution

    After the end of the initially section, the process (if present) is started and executes in parallel with all other processes.


    Concurrent updates

    Concurrent Updates

    object A

    process

    m <-ba.withdraw[100]

    end process

    end A

    object B

    process

    m <- ba.withdraw[100]

    end process

    end B


    Synchronization required

    Synchronization Required

    Classic Monitors as described by Tony Hoare

    Example: hi – ho program (synch.m)


    Alternatives

    Alternatives

    • Semaphore – go thru example (sem.m)

    • Rendez-vous

    • Barrier


    Distribution

    Distribution

    • Sea of objects (draw)

    • Sea is dividedintodisjunct parts called Nodes

    • An object is onone and onlyone Node at a time

    • Each node is represented by a Nodeobject


    Location primitive

    Location Primitive

    • Locate X returns the node where X is (was!)

    • Note that the objectmayalready have moved to another node (actuallyanynumber of moves)


    Mobility primitive

    Mobility Primitive

    Basic primitive is move X to Y

    The object X is moved where Y is.

    More formally: The object denoted by the expression X is move to the node where the object denoted by expression Y was!

    If the move cannot be done, it is ignored.

    NOTHING is guaranteed – nothing may happen.


    Strong move fix

    Strong Move: Fix

    Basic primitive is fix X at Y

    The object X is moved where Y is & stays there.

    More formally: The object denoted by the expression X is move to the node where the object denoted by expression Y was!

    Either the move happens – or it fails.

    Strong guarantees; potentially expensive


    Immutable objects

    Immutable Objects

    Immutable objects are omnipresent so moving them does nothing and ALWAYS succeeds.


    Mobility example

    objectBoss

    process

    var w: Worker

    var n: Node

    n <- …find usablenode

    moveself to n

    w <- Worker.create[ ]

    end process

    end Boss

    classWorker

    process

    do work…

    end process

    end Worker

    Mobility Example


    Mobility example1

    object Boss

    var w: Worker

    var n: Node

    n <- …find usable node

    w <-Worker.create[ ]

    move w to n

    w.StartWork[ ]

    end Boss

    classWorker

    op StartWork

    slave <- object slave

    process

    work… work

    end process

    end StartWork

    end Worker

    Mobility Example


    Why two different moves

    Why two different moves?

    • Fast efficient – mobility hint

    • Slow but sure for when location is part of the semantics of the application.


    Why mobility

    Why Mobility

    • Localcallsaretypically 1,000 – 10,000 times faster thanremotecalls

    • Mobility for:

      • performance

      • availability


    Mobility and location concepts

    Mobility and Location Concepts

    locate X returns(one of) the object X’s

    locations

    move X to Y movethe object X to the node

    whereY is (orratherwas)

    fix X at Y as move but disregard

    subsequentmoves

    refix X at Y as fix but for fixedobjects

    unfix X allownormal moves


    Call by move

    var B: some data object

    X.F[move B]

    object X

    operation F[arg:T]

    loop

    arg.g[…]

    exit after

    manyloops

    end loop

    end X

    Call-by-move


    Call by visit

    var B: some data object

    X.F[move B]

    X.F[visit B]

    object X

    operation F[arg:T]

    loop

    arg.g[…]

    exit after

    manyloops

    end loop

    end X

    Call-by-visit


    How many calls of b

    How Many Calls of B?

    Questions: given a normal PC enviroment, say 2 GHz CPU, 100 Mbit/s Ethernet, howmanycalls of a small (say 100 bytes) argument B beforebreakeven?

    • 1

    • 10

    • 100

    • 1,000

    • 10,000

    • 100,000

    • 1,000,000


    Return by move

    Return-by-move

    When an operation creates a result object and knows it is for the caller’s use only, it can choose to return the parameter by move.

    Return-by-move is not necessary – but increases efficiency – why??


    Killroy

    objectKillroy

    process

    var myNode <- locateself

    var up: array.of[Nodes]

    up <- myNode.getNodes[]

    foreach n in up

    moveself to n

    end foreach

    end process

    end Killroy

    Objectmovesitself to all available nodes

    On the original MicroVAX( 1987) implementation: 20 moves/second!

    Note: the thread (called a process in Emerald) movesalong

    Killroy


    Attachment

    Attachment

    Problem:

    move an object but its internal data structure does not move along!

    Classic example:

    A tree


    Emerald et oo spr k for distribuerte applikasjoner review concurrency mobility

    Tree

    class TreeClass

    var left, right: TreeClass

    var data: …

    end TreeClass


    Attached tree

    Attached Tree

    class TreeClass

    attached var left, right: TreeClass

    var data: …

    end TreeClass


    Attachment can it be decided automatically

    Attachment: can it be decided automatically?

    Tree example

    TreeNode

    left, right

    Mail message

    To

    From

    Subject

    Body


    Attachment costs

    Attachment costs

    Attachment has NO run-time cost!

    Just a bit in the DESCRIPTOR for an object.

    One bit for each variable.

    Better: compiler sorts by attached bit – then merely two integers, e.g.,

    5 attached variables

    4 non-attached variables


    Dynamic attachment

    Dynamic Attachment

    var X: … <- something

    attached varaX: …

    Join:

    aX <- X

    Leave:

    aX <- NIL


    Conclusion

    Conclusion

    Emerald has

    • concurrency with Hoare monitors

    • fully integrated distribution facilities

    • has full on-the-fly mobility

    • a novel attachment language feature

      Many novel implementation techniques (more talks to come!)


  • Login