1 / 13

Reminders

Reminders. 1 st Erlang assignment due Friday, Apr. 3 2 nd mid-term in-class Monday, Apr. 6. Questions about Assignment. Interpreting error messages: Error in process <0.38.0> with exit value: {function_clause,[{ring,waitSend,[<0.39.0>]}]}

rahim-hunt
Télécharger la présentation

Reminders

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. Reminders • 1st Erlang assignment due Friday, Apr. 3 • 2nd mid-term in-class Monday, Apr. 6

  2. Questions about Assignment • Interpreting error messages: Error in process <0.38.0> with exit value: {function_clause,[{ring,waitSend,[<0.39.0>]}]} Exit values are documented in the Erlang manual online. This one means: died trying to call ring:waitSend with argument <0.39.0> (a Pid) because there was no matching function clause. Problem: the argument name began with a lowercase letter.

  3. Objects simulated in C • In C, objects can be emulated by using structs typedef obj = struct {m1type *m1; m2type *m2; d1type d1… } obj *o1 = oFactory(…init values); o1->m1(o1, …); • C function pointers refer only to function code; not function closures (code together with lookup environment) so all data needed to specialize the code has to be included in the struct • Conceptually not hard, but requires explicit code to do it

  4. Objects simulated in functional style • Objects can be simulated using records that contain function closures • First, for only a single method we don’t need a record: newFoo(InitState) -> (fun(NewState)-> (InitState, newFoo(NewState)) end). F0 = newFoo(3). {V1, F1} = F0(hi). {V2, F2} = F1(6).

  5. Using a tuple (easily extend to record so methods have names) newFoo(InitState) -> { fun (Args1) -> {f11(InitState, Args1), newFoo(f12(InitState, Args1))} end, fun (Args2) -> {f21(InitState, Args2), newFoo(f22(InitState, Args2))} end, … }.

  6. Using Processes its clearer and easier newServer(InitState) -> Server = spawn(server), {fun(Args1) -> rpc(Server, {f1, Args1}), fun(Args2) -> rpc(Server, {f2, Args2}), … } end. • rpc here is just the same rpc function we’ve seen before • f1 and f2 are atoms in this context

  7. The server server(State) -> receive {From, {f1, Args1}} -> From ! f11(State, Args1), server(f12(State, Args1)); {From, {f2, Args2}} -> From ! f21(State, Args2), server(f22(State, Args2)) … end. • f11, f12, f21, and f22 are the same functions as in the purely sequential simulation

  8. The client Server1 = newServer(SomeState), {F1, F2} = Server, V1 = F1(Args1), V2 = F2(Args2), % note V2 depends on both Args1 and Args2 as well as SomeState Server2 = newServer(SomeOtherState), V3 = F1(OtherArgs1), V4 = F2(OtherArgs2), % note V4 depends on OtherArgs1 and 2 and SomeOtherState but not on SomeState, Args1 and Args2

  9. The behavior is not quite the same • If the sequential simulation is used from multiple processes each gets its own “fork” of the object history • Because the way it is used results in a new object every time a method is called • The process simulation involves only a single object that, oh by the way, has synchronized access • A process, inherently, does only one thing at a time

  10. A complete, simple example -module(tester). -export([start/1]). start(Id) -> Server = spawn(fun () -> serverloop(Id, []) end), fun(Item) -> rpc( Server, Item ) end . serverloop(Id, History) -> receive { From, Something } -> io:format( "Server ~p: Got ~p from ~p with history ~p~n", [Id, Something, From, History] ), From ! { self(), ok }, serverloop(Id, [Something|History]) end.

  11. Exam Review • Material covered: • Thread pools – pool sizing; thread-starvation; policies • GUI issues – why single threaded; model-view-controller; idea of listeners; when and how to use concurrency • Deadlocks – wait-for graph; lock ordering; livelock; starvation; lock performance; processor atomic operations • Testing issues – not covered • Erlang • Sequential – single assignment variables; lists; pattern matching • Concurrent – mailboxes, send and receive primitives, pattern matching on the mailbox, linked processes, system processes • Function closures and their use • You may use your notes on your computer; also any compiler. Turn off/disable the network!

More Related