1 / 23

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

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 two lecture series (F1, F2): Everything is an object Algol-60/Simula/Smalltalk heritage

hetal
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Emerald - et OO-språk for distribuerteapplikasjonerReview – Concurrency - Mobility Eric Jul OMS Professor II

  2. Emerald Review We’ll start with a review of Emerald from the first two lecture series (F1, F2): • Everything is an object • Algol-60/Simula/Smalltalk heritage • Object constructors • Conformity based type system – think interfaces

  3. 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

  4. 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

  5. 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

  6. Conformityinformally(substitution) A type A conforms to another type B when any object that conforms to A can be used anywhere something of type B is required. Substitution principle. Means A is as larger or larger than B.

  7. 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 BankAccountconforms to DepositOnlyBankAccountbecause it support all the require operations – and the parameters alsoconform What is conformity?

  8. Conformity details • Conformity is implicit. • It is a mathematical relation • No ”implements” as in Java • Operation namesimportant • Parameter namesdo not matter, just theirtypes matters. (Parameter name for documentationonly.) • Aritymatters: foo(char) different from foo(char, float)

  9. Conformity more formally NOT IMPORTANT HERE

  10. 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.)

  11. 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

  12. Process Concept A process is a thread of execution. Every object can have ONE process. (Or none, but can also be modelled as a process that is “empty”.) Process section in object constructor

  13. Synchronization Required Classic Monitors as described by Tony Hoare Example: hi – ho program (synch.m)

  14. 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 • Locate X returns the node where X is (was!)

  15. Immutable Objects • Immutable objects cannot change state • Examples: The integer 17 • User-defined immutable objects: for example complex numbers • Immutable objects are omnipresent • Types must be immutable to allow static type checking

  16. Types are Immutable Objects Example: arrays varai: Array.of[Integer] ai <- Array.of[Integer].create[] varaai: Array.of[Array.of[Integer]]

  17. WhyMobility? • Localcallsaretypically 1,000 – 10,000 times faster thanremotecalls • Mobility for: • performance • availability

  18. Mobility and Location Concepts locate X returns (one of) the object X’s locations move X to Y move the object X to the node where Y is (orratherwas) fix X at Y as move but disregard subsequentmoves refix X at Y as fix but for fixedobjects unfix X allow normal moves

  19. var B: some data object … X.F[move B] … … X.F[visit B] … object X operation F[arg:T] loop arg.g[…] exit after many loops end loop end X Call-by-move

  20. How Many Calls of B? Questions: given a normal PC enviroment, say 2 GHz CPU, 10 Mbit/s Ethernet, howmanycalls of a small (say 100 bytes) argument B beforebreakeven? • 1 • 10 • 100 • 1,000 • 10,000 • 100,000

  21. 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 Object moves itself to all available nodes On the original MicroVAX implementation: 20 moves/second Note: the thread (called a process in Emerald) moves along Killroy

  22. Attachment Tree example TreeNode left, right Mail message To From Subject Body

  23. GrundliggendeDistribution • Remote References: Local &Global Objects • RPC – remote procedure call • Implementation of RPC • Location concept • Simple mobility • Asynchronous operations in Emerald • Immutability and its uses

More Related