1 / 46

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

kaida
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 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)

  3. People

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

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

  6. ClasslessObject Construction Objectconstructors: objectseqno var prev: Integer = 0 Integer operation getSeqNo[] prev <- prev +1 returnprev end getSeqno end seqno The above is an executableexpression!

  7. Object Constructors • Execution results in a new object • Execute again – and get yet another object • No class! Want classes?

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

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

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

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

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

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

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

  15. Conformity more formally NOT IMPORTANT HERE

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

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

  18. TODAY (F2) • Process concept (Emerald proces = thread) • Synchronization using Monitors

  19. Process Concept A process is a thread of execution. Every object can have ONE process. Process section in object constructor

  20. Process section object A initially … initializestuff end initially process … do something end process end A

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

  22. Concurrent Updates object A process m <-ba.withdraw[100] end process end A object B process m <- ba.withdraw[100] end process end B

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

  24. Alternatives • Semaphore – go thru example (sem.m) • Rendez-vous • Barrier

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

  26. Location Primitive • Locate X returns the node where X is (was!) • Note that the objectmayalready have moved to another node (actuallyanynumber of moves)

  27. Mobility Primitive Basic primitive is moveX 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.

  28. 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 guarentees; potentially expensive

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

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

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

  32. Why two different moves? • Fast efficient – mobility hint • Slow but sure for when location is part of the semantics of the application.

  33. Why Mobility • Localcallsaretypically 1,000 – 10,000 times faster thanremotecalls • Mobility for: • performance • availability

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

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

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

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

  38. 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??

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

  40. Attachment Problem: move an object but its internal data structure does not move along! Classic example: A tree

  41. Tree class TreeClass var left, right: Node var data: … end TreeClass

  42. Attached Tree class TreeClass attached var left, right: Node var data: … end TreeClass

  43. Attachment: can it be decided automatically? Tree example TreeNode left, right Mail message To From Subject Body

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

  45. Dynamic attachment var X: … <- something attached varaX: … … Join: aX <- X Leave: aX <- NIL

  46. 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!)

More Related