Recent Changes for "Concurrency" - spark-scheme

Concurrency

vijaymathew — 2009-08-10 17:09:24

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 284:	Line 284:
- ;; Modify global state here. - )	+ (begin + ;; Modify global state here. + ))
Line 297:	Line 298:
- ;; Modify global state here. - )	+ (begin + ;; Modify global state here. + ))

Concurrency

vijaymathew — 2009-08-10 17:08:49

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 282:	Line 282:
- ;; Global state is BAD!! - > (define global-state 0)
Line 286:	Line 284:
- (set! global-state (add1 global-state)))) - > (async modify-global-state) - > (async modify-global-state) - > global-state - 2	+ ;; Modify global state here. + )
Line 300:	Line 295:
- (define (counter-with-named-atomic) - (atomic "counter" - (begin - (set! count (add1 count)) - (printf "~a " count)))) - - }}}	+ > (define (modify-global-state) + (atomic "lock-name" + ;; Modify global state here. + ) + + }}} + + All constant-time procedures and operations are thread-safe because they are atomic. For example, ''set!'' assigns to a variable as an atomic action with respect to all threads, so that no thread can see a "half-assigned" variable. Similarly, ''vector-set!'' assigns to a vector atomically. The ''hash-table-put!'' procedure is not atomic, but the table is protected by a lock. Port operations are generally not atomic, but they are thread-safe in the sense that a byte consumed by one thread from an input port will not be returned also to another thread, and procedures like ''port-commit-peeked'' and ''write-bytes-avail'' offer specific concurrency guarantees. See ["MzScheme Library Reference"] for more information.

Concurrency

vijaymathew — 2009-08-10 17:03:34

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 278:	Line 278:
- The preferred paradigm for Spark is [http://www.defmacro.org/ramblings/fp.html Functional Programming]. Spark is not a pure functional language. It means that there is nothing in the language that ''prevents'' you from sharing state across processes. If two processes modify a shared resource at the same time, that might lead to data corruption and incorrect program behavior. Spark provides the special form ''atomic'' to prevent a piece of code from being executed by two processes at the same time. If the portion of code that writes to the shared state is ''atomic'', it is guaranteed that it won't be modified by two processes simultaneously. Note that the following samples are rather contrived, as ''set!'' is already atomic.	+ The preferred paradigm for Spark is [http://www.defmacro.org/ramblings/fp.html Functional Programming]. Spark is not a pure functional language. It means that there is nothing in the language that ''prevents'' you from sharing state across processes. If two processes modify a shared resource at the same time, that might lead to data corruption and incorrect program behavior. Spark provides the special form ''atomic'' to prevent a piece of code from being executed by two processes at the same time. If the portion of code that writes to the shared state is ''atomic'', it is guaranteed that it won't be modified by two processes simultaneously.

Concurrency

vijaymathew — 2009-08-10 17:01:40

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 278:	Line 278:
- The preferred paradigm for Spark is [http://www.defmacro.org/ramblings/fp.html Functional Programming]. Spark is not a pure functional language. It means that there is nothing in the language that ''prevents'' you from sharing state across processes. If two processes modify a shared resource at the same time, that might lead to data corruption and incorrect program behavior. Spark provides the special form ''atomic'' to prevent a piece of code from being executed by two processes at the same time. If the portion of code that writes to the shared state is ''atomic'', it is guaranteed that it won't be modified by two processes simultaneously.	+ The preferred paradigm for Spark is [http://www.defmacro.org/ramblings/fp.html Functional Programming]. Spark is not a pure functional language. It means that there is nothing in the language that ''prevents'' you from sharing state across processes. If two processes modify a shared resource at the same time, that might lead to data corruption and incorrect program behavior. Spark provides the special form ''atomic'' to prevent a piece of code from being executed by two processes at the same time. If the portion of code that writes to the shared state is ''atomic'', it is guaranteed that it won't be modified by two processes simultaneously. Note that the following samples are rather contrived, as ''set!'' is already atomic.

Concurrency

vijaymathew — 2009-08-09 17:26:16

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 302:	Line 302:
- (set! count (add1 count)) - (printf "~a " count))) - - }}}	+ (begin + (set! count (add1 count)) + (printf "~a " count)))) + + }}}

Concurrency

vijaymathew — 2009-07-22 14:17:46

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 296:	Line 296:
- Usually ''atomic'' makes use of a single, global synchronization object. New, special purpose synchronization objects can be created using ''named atomics''. Code blocks can choose which synchronization object to use by specifying it's name.	+ Usually ''atomic'' makes use of a single, global synchronization object. New, special purpose synchronization objects can be created using ''named atomics''. Code blocks can choose which synchronization object to use by specifying its name.

Concurrency

vijaymathew — 2009-07-22 14:17:35

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 264:	Line 264:
- If you have programmed in languages like Java or Python, you might have used ''threads'' to simulate concurrency. Spark too have threads. But unlike the aforementioned languages, Spark's multi-threading capabilities are not dependent on the host operating system. Threads is part of the Spark runtime itself. A new thread is created with a call to the ''thread'' procedure. It takes another procedure as it's argument, which will be execute in the new thread. The return value is a thread descriptor object.	+ If you have programmed in languages like Java or Python, you might have used ''threads'' to simulate concurrency. Spark too have threads. But unlike the aforementioned languages, Spark's multi-threading capabilities are not dependent on the host operating system. Threads is part of the Spark runtime itself. A new thread is created with a call to the ''thread'' procedure. It takes a procedure as argument, which will be execute in the new thread. The return value is a thread descriptor object.

Concurrency

vijaymathew — 2009-07-22 14:17:10

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 244:	Line 244:
- '''(async proc args-list callback-proc)''': ''proc'' is the procedure to be executed asynchronously. ''args-list'' is a list of arguments that will be passed to ''proc''. This should be null if ''proc'' does not take any argument. ''callback-proc'' is a procedure that will be called once ''proc'' is done. ''callback-proc'' will receive as it's argument the value that ''proc'' evaluates to. ''callback-proc'' can be null.	+ '''(async proc args-list callback-proc)''': ''proc'' is the procedure to be executed asynchronously. ''args-list'' is a list of arguments that will be passed to ''proc''. This should be null if ''proc'' does not take any argument. ''callback-proc'' is a procedure that will be called once ''proc'' is done. ''callback-proc'' will receive as argument the value that ''proc'' evaluates to. ''callback-proc'' can be null.

Concurrency

vijaymathew — 2009-07-22 14:16:55

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 215:	Line 215:
- Now clients can send messages to "trig-server" by appending the machine name or IP to it's identifier. Here is a sample client that can interact with the remote trig-server:	+ Now clients can send messages to "trig-server" by appending the machine name or IP to its identifier. Here is a sample client that can interact with the remote trig-server:

Concurrency

vijaymathew — 2009-07-22 14:16:46

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 171:	Line 171:
- The process represented by ''test-server'' can be brought under watch by passing it's proc-id to ''watch-server''. When it dies, it is restarted by the watcher. This is demonstrated in the following session:	+ The process represented by ''test-server'' can be brought under watch by passing its proc-id to ''watch-server''. When it dies, it is restarted by the watcher. This is demonstrated in the following session:

Concurrency

vijaymathew — 2009-07-22 14:16:35

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 89:	Line 89:
- Let us extend the trig-server with a complete implementation of inter-process communication. The client process should include it's process id as the first element of the message. ''trig-server'' will compute the result and send it back to the client.	+ Let us extend the trig-server with a complete implementation of inter-process communication. The client process should include its process id as the first element of the message. ''trig-server'' will compute the result and send it back to the client.

Concurrency

vijaymathew — 2009-07-22 14:16:23

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 72:	Line 72:
- Now we can send messages to the trigonometry object and have the results printed. As this object lives in it's own parallel world, we can go on with other business as it does the computations.	+ Now we can send messages to the trigonometry object and have the results printed. As this object lives in its own parallel world, we can go on with other business as it does the computations.

Concurrency

vijaymathew — 2009-07-22 14:16:16

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 63:	Line 63:
- To use the ''trig server'', load ''trig-server.ss'' into Spark and spawn a process with the procedure ''trig-server'' as it's callback.	+ To use the ''trig server'', load ''trig-server.ss'' into Spark and spawn a process with the procedure ''trig-server'' as its callback.

Concurrency

vijaymathew — 2009-07-16 15:22:10

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 295:	Line 295:
	+ + Usually ''atomic'' makes use of a single, global synchronization object. New, special purpose synchronization objects can be created using ''named atomics''. Code blocks can choose which synchronization object to use by specifying it's name. + + {{{ + + (define (counter-with-named-atomic) + (atomic "counter" + (set! count (add1 count)) + (printf "~a " count))) + + }}}

Concurrency

vijaymathew — 2009-07-16 15:17:28

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 278:	Line 278:
- The preferred paradigm for Spark is [http://www.defmacro.org/ramblings/fp.html Functional Programming]. ''(see the section on Concurrency)''. Spark is not a pure functional language. It means that there is nothing in the language that ''prevents'' you from sharing state across processes. If two processes modify a shared resource at the same time, that might lead to data corruption and incorrect program behavior. Spark provides the special form ''atomic'' to prevent a piece of code from being executed by two processes at the same time. If the portion of code that writes to the shared state is ''atomic'', it is guaranteed that it won't be modified by two processes simultaneously.	+ The preferred paradigm for Spark is [http://www.defmacro.org/ramblings/fp.html Functional Programming]. Spark is not a pure functional language. It means that there is nothing in the language that ''prevents'' you from sharing state across processes. If two processes modify a shared resource at the same time, that might lead to data corruption and incorrect program behavior. Spark provides the special form ''atomic'' to prevent a piece of code from being executed by two processes at the same time. If the portion of code that writes to the shared state is ''atomic'', it is guaranteed that it won't be modified by two processes simultaneously.

Concurrency

vijaymathew — 2009-07-16 15:16:30

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 264:	Line 264:
- If you have programmed in languages like Java or Python, you might have used ''threads'' to simulate concurrency. Spark too have threads. But unlike the aforementioned languages, Spark's multi-threading capabilities are not dependent on the host operating system. Threads is part of the Spark runtime itself. A new thread is created with a call to the ''thread'' procedure. It takes a procedure as it's argument, which will be execute in the new thread. The return value is a thread descriptor object.	+ If you have programmed in languages like Java or Python, you might have used ''threads'' to simulate concurrency. Spark too have threads. But unlike the aforementioned languages, Spark's multi-threading capabilities are not dependent on the host operating system. Threads is part of the Spark runtime itself. A new thread is created with a call to the ''thread'' procedure. It takes another procedure as it's argument, which will be execute in the new thread. The return value is a thread descriptor object.

Concurrency

vijaymathew — 2009-07-16 15:15:51

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 244:	Line 244:
- '''(async proc args-list callback-proc)''': ''proc'' is the procedure to be executed asynchronously. ''args-list'' is a list of arguments that will be passed to ''proc''. This should be null if ''proc'' does not take any arguments. ''callback-proc'' is a procedure that will be called once ''proc'' is done. ''callback-proc'' will receive as it's argument the value that ''proc'' evaluates to. ''callback-proc'' can be null.	+ '''(async proc args-list callback-proc)''': ''proc'' is the procedure to be executed asynchronously. ''args-list'' is a list of arguments that will be passed to ''proc''. This should be null if ''proc'' does not take any argument. ''callback-proc'' is a procedure that will be called once ''proc'' is done. ''callback-proc'' will receive as it's argument the value that ''proc'' evaluates to. ''callback-proc'' can be null.

Concurrency

vijaymathew — 2009-07-16 15:15:04

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 242:	Line 242:
- An asynchronous procedures can be used to get a time consuming computation done in the background. It is another way of creating processes without the messaging infrastructure. The computation is defined as a procedure and invoke it with a call to ''async''.	+ Asynchronous procedures can be used to get a time consuming computation done in the background. It is another way of creating processes, without the messaging infrastructure. The computation is defined as a procedure which is evaluated using ''async''.

Concurrency

vijaymathew — 2009-07-16 15:14:07

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 237:	Line 237:
- Note the way we specify the remote process id appended with the machine name. We need to start the ''remoting'' service so as to get back the responses send by ''trig-server''. We start the client side remoting service on port 1445, because the default port 1383 is already bound by ''trig-server''. If the server and client processes are actually running on two machines, we need not change the port. Thus components in a Spark program can be distributed across a network with very little additional programming effort. This is an important feature for a language that lives in the age of "cloud computing". One other language that offer this convenience is [http://erlang.org/ Erlang], which inspired and influenced the design of Spark concurrent objects.	+ Note the way we specify the remote process id appended with the machine name. We need to start the ''remoting'' service so as to get back the responses send by ''trig-server''. We start the client side remoting service on port 1445, because the default port 1383 is already bound by ''trig-server''. If the server and client processes are actually running on two machines, we need not change the port. Thus components in a Spark program can be distributed across a network with very little additional programming effort. One other language that offer this convenience is [http://erlang.org/ Erlang], which inspired and influenced the design of Spark concurrent objects.

Concurrency

vijaymathew — 2009-07-16 15:13:05

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 215:	Line 215:
- Now clients can send messages to "trig-server" by appending the machine name or IP to it. Here is a sample client that can interact with the remote trig-server:	+ Now clients can send messages to "trig-server" by appending the machine name or IP to it's identifier. Here is a sample client that can interact with the remote trig-server:

Concurrency

vijaymathew — 2009-07-16 15:12:27

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 203:	Line 203:
- In distributed computing a program is split up into parts that run simultaneously on multiple computers communicating over a network. Spark processes can be made to send and receive messages over the network. This does not require any extensive modification of existing code. A client process can send messages to a server process running on another machine using the ''send'' procedure itself. The server process on the other end of the network can use the same old ''receive'' procedure to get the request. We need to use a new procedure, though. This is called ''remoting!'' and it starts an internal TCP server that acts as a mediator between the distributed processes. The programmer need not worry about how the messages are packed, delivered and unpacked over the wire. All that is taken care of by the ''send'', ''receive'' and ''remoting!'' procedure calls. The ''trig-server'' we have written can serve clients in a networked environment, without any modification. Let us see how to start it as a server process:	+ In distributed computing a program is split into parts that run simultaneously on multiple computers communicating over a network. Spark processes can be made to send and receive messages over the network. This does not require any extensive modification of existing code. A client process can send messages to a server process running on another machine using the ''send'' procedure itself. The server process on the other end of the network can use the same old ''receive'' procedure to get the request. To actually send and receive messages over the network, we need a new procedure, though. This is called ''remoting!'' and it starts an internal TCP server that acts as a mediator between the distributed processes. The programmer need not worry about how the messages are packed, delivered and unpacked over the wire. All of that is taken care of by the ''send'', ''receive'' and ''remoting!'' procedure calls. The ''trig-server'' we have written can serve clients in a networked environment, without any modification. Let us see how to start it as a server process:

Concurrency

vijaymathew — 2009-07-16 15:10:36

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 201:	Line 201:
- ==== Processes and distributed computing ====	+ ==== Distributed computing ====

Concurrency

vijaymathew — 2009-07-16 15:10:22

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 190:	Line 190:
	+
Line 191:	Line 192:
	+
Line 192:	Line 194:
	+
Line 193:	Line 196:
- '''(descriptor proc-id)''': Returns the thread descriptor object that the process internally uses. - '''(message-channel proc-id)''': Returns the asynchronous message channel object that the process internally uses.	+ + '''(descriptor proc-id)''': Returns the thread descriptor object that the process uses internally. + + '''(message-channel proc-id)''': Returns the asynchronous message channel object that the process uses internally.

Concurrency

vijaymathew — 2009-07-16 15:09:18

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 148:	Line 148:
- A system is ''fault tolerant'' if it can detect errors and repair itself. Spark process can have fault tolerance with the help of ''watcher'' processes. A ''watcher'' process is notified by the system when a ''watched'' process dies or exits. The following code snippet introduces the procedure ''watch'' that enables a process to keep an eye on another process:	+ A system is ''fault tolerant'' if it can detect errors and repair itself. A Spark process implements fault tolerance with the help of ''watcher'' processes. A ''watcher'' process is notified by the system when a ''watched'' process die or exit. The following code snippet introduces the procedure ''watch'' that enables a process to keep an eye on another process:

Concurrency

vijaymathew — 2009-07-16 15:08:35

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 146:	Line 146:
- ==== Processes and fault tolerance ====	+ ==== Fault tolerance ====

Concurrency

vijaymathew — 2009-07-16 15:08:22

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 144:	Line 144:
- With concurrent objects we have a powerful tool to model the real world. Like objects in the real world, Spark processes live and execute independently. They interact with each other using messages. As they need not share memory, programs can be written without worrying about synchronization and locks. Spark's concurrent objects are an implementation of the [http://en.wikipedia.org/wiki/Actor_model Actor model] and brings the experienced programmer to a previously unknown intimacy with pure [http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en Object Oriented Programming].	+ Concurrent objects gives us a powerful tool to model the world around us. Like objects in the real world, Spark processes live and execute independently. They interact with each other using messages. As they need not share memory, programs can be written without worrying about synchronization and locks. Spark's concurrent objects are an implementation of the [http://en.wikipedia.org/wiki/Actor_model Actor model] and brings the experienced programmer to a previously unknown intimacy with pure [http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en Object Oriented Programming].

Concurrency

vijaymathew — 2009-07-16 15:07:31

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 128:	Line 128:
- To try our changed code, you need to load both trig-server.ss and trig-client.ss:	+ To try our new code, we need to load both trig-server.ss and trig-client.ss:

Concurrency

vijaymathew — 2009-07-16 15:07:13

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 115:	Line 115:
- Here is a client process that can interact with the ''trig-server''. It is wrapped up in a procedure that takes the server process id, the trig function and the value to apply the trig function. Internally we spawn a new process that will send the request to the server, get the response and print it.	+ Here is a client process that can interact with the ''trig-server''. It is wrapped up in a procedure that takes the server process id, the trig function and the value to apply the trig function to. Internally we spawn a new process that will send the request to the server, get the response and print it.

Concurrency

vijaymathew — 2009-07-16 15:06:32

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 89:	Line 89:
- Let us extend the trig-server with a complete implementation of inter-process communication. The sending process should include it's process id as the first element of the message. ''trig-server'' will compute the result and send it back to that process.	+ Let us extend the trig-server with a complete implementation of inter-process communication. The client process should include it's process id as the first element of the message. ''trig-server'' will compute the result and send it back to the client.

Concurrency

vijaymathew — 2009-07-16 15:05:27

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 72:	Line 72:
- Now we can send messages to the trigonometry object and have the results printed. As this object lives in it's own parallel world, we can go on with other businesses as it does the computations.	+ Now we can send messages to the trigonometry object and have the results printed. As this object lives in it's own parallel world, we can go on with other business as it does the computations.

Concurrency

vijaymathew — 2009-07-16 15:04:57

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 35:	Line 35:
- Let us try to get a better understanding of concurrent objects with the help of a simple example. Here we define an object that can act as a background service for doing trigonometric calculations. It waits for messages in a loop. A message is packed as a list data structure with the first element identifying the trigonometric function and the rest of the elements being it's arguments. When a message arrives, it is unpacked using the ''match'' procedure and an appropriate trigonometric function is executed and the result is displayed. If it receives the special message 'exit, the concurrent object kills itself.	+ Let us study a small program where concurrent objects are put to good use. Here we define an object that can act as a background service for doing trigonometric calculations. It waits for messages in a loop. A message is packed as a list with the first element identifying the trigonometric function and the rest of the elements being that function's arguments. When a message arrives, it is unpacked using the ''match'' procedure and an appropriate trigonometric function is executed and the result is displayed. If it receives the special message 'exit, the concurrent object kills itself.

Concurrency

vijaymathew — 2009-07-16 15:03:33

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 16:	Line 16:
- '''(spawn proc)''': Creates a new process that evaluates the procedure ''proc''. The return value is an integer that identifies the process. It can take ''n'' number of optional arguments which can be used to initialize the state of the new process. - '''(send pid)''': Sends a message to the process identified by ''pid''. Message sending is asynchronous. - '''(receive pid)''': Receives a message from the message queue of the process identified by ''pid''. Calls to ''receive'' usually make use of the pattern matching facility provided by the ''match'' library. ''receive'' usually follows coding pattern given below:	+ '''(spawn proc)''': Creates a new process. The procedure represented by ''proc'' is evaluated in that process. The return value of ''spawn'' is an integer that identifies the new process. It can take ''n'' number of optional arguments which can be used to initialize the state of the new process. + + '''(send pid)''': Asynchronously sends a message to the process identified by ''pid''. + + '''(receive pid)''': Receives a message from the message queue of the process identified by ''pid''. Calls to ''receive'' usually make use of the pattern matching facility provided by the ''match'' library. ''receive'' usually follows the coding pattern given below:

Concurrency

vijaymathew — 2009-07-16 15:01:30

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 9:	Line 9:
- Spark allows several computations to execute simultaneously, possibly interacting with each other. In programming parlance this is known as multi-processing, multi-threading, concurrency etc. Programming languages usually depend on the host operating systems capabilities to implement concurrency. Spark has built-in concurrency. It provide multi-threading without any help from the underlying operating system. This has some important consequences:	+ Spark allows several computations to execute simultaneously, possibly interacting with each other. In programming parlance this is known as multi-processing, multi-threading, concurrency etc. Programming languages usually depend on the host operating system's capabilities to implement concurrency. Spark has built-in concurrency. It provide multi-threading without any help from the underlying operating system. This has some important consequences:

Concurrency

vijaymathew — 2009-06-21 12:49:27

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 267:	Line 267:
- See the [MzScheme library reference http://spark-scheme.wikispot.org/MzScheme_Library_Reference] for more information on threads.	+ See the MzScheme library reference [http://spark-scheme.wikispot.org/MzScheme_Library_Reference] for more information on threads.

Concurrency

vijaymathew — 2009-06-21 12:49:10

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 267:	Line 267:
- See the [MzScheme library reference "http://spark-scheme.wikispot.org/MzScheme_Library_Reference"] for more information on threads.	+ See the [MzScheme library reference http://spark-scheme.wikispot.org/MzScheme_Library_Reference] for more information on threads.

Concurrency

vijaymathew — 2009-06-21 12:48:49

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 10:	Line 10:
	+
Line 15:	Line 16:
- '''(spawn proc)''': Creates a new process that evaluates the procedure ''proc''. The return value is an integer that identifies the process. It takes an optional arguments which can be used to initialize the state of the new process.	+ '''(spawn proc)''': Creates a new process that evaluates the procedure ''proc''. The return value is an integer that identifies the process. It can take ''n'' number of optional arguments which can be used to initialize the state of the new process.
Line 17:	Line 18:
- '''(receive pid)''': Receives a message from the message queue of the process identified by ''pid''. Calls to ''receive'' usually make use of the pattern matching facility provided by the ''match'' library and has the following coding pattern:	+ '''(receive pid)''': Receives a message from the message queue of the process identified by ''pid''. Calls to ''receive'' usually make use of the pattern matching facility provided by the ''match'' library. ''receive'' usually follows coding pattern given below:
Line 32:	Line 33:
- Let us try to get a better understanding of concurrent objects with the help of a simple example. Here we define an object that can act as background service for doing trigonometric calculations. It waits for messages in a loop. A message is packed as a list data structure with the first element identifying the trigonometric function to execute and the rest of the elements being it's arguments. When a message arrives, it is unpacked using the ''match'' procedure and an appropriate trigonometric function is executed and the result is displayed. If it receives the special message 'exit, the concurrent object kills itself.	+ Let us try to get a better understanding of concurrent objects with the help of a simple example. Here we define an object that can act as a background service for doing trigonometric calculations. It waits for messages in a loop. A message is packed as a list data structure with the first element identifying the trigonometric function and the rest of the elements being it's arguments. When a message arrives, it is unpacked using the ''match'' procedure and an appropriate trigonometric function is executed and the result is displayed. If it receives the special message 'exit, the concurrent object kills itself.
Line 69:	Line 70:
- Now we can send messages to the trigonometry object and have the results printed. As this object lives in it's own parallel world, we can go on with our business as it does the computations.	+ Now we can send messages to the trigonometry object and have the results printed. As this object lives in it's own parallel world, we can go on with other businesses as it does the computations.
Line 112:	Line 113:
- Here is a client process that can interact with the ''trig-server''. It is wrapped up in a procedure that takes the server process id, the trig function and it's argument as it's parameters. Internally we spawn a new process that will send the request to the server get the response and print it.	+ Here is a client process that can interact with the ''trig-server''. It is wrapped up in a procedure that takes the server process id, the trig function and the value to apply the trig function. Internally we spawn a new process that will send the request to the server, get the response and print it.
Line 125:	Line 126:
- To try our changed code, you need to load both trig-server.ss and trig-client.ss to the Spark environment.	+ To try our changed code, you need to load both trig-server.ss and trig-client.ss:
Line 141:	Line 142:
- With concurrent objects we have a powerful tool to model the real world in software. Like objects in the real world, Spark processes live and execute independently. They interact with other using messages. As they need not share memory, programs can be written without worrying about synchronization and locks. Spark's concurrent objects are an implementation of the [http://en.wikipedia.org/wiki/Actor_model Actor model] and brings the experienced programmer to a previously intimacy with pure [http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en Object Oriented Programming].	+ With concurrent objects we have a powerful tool to model the real world. Like objects in the real world, Spark processes live and execute independently. They interact with each other using messages. As they need not share memory, programs can be written without worrying about synchronization and locks. Spark's concurrent objects are an implementation of the [http://en.wikipedia.org/wiki/Actor_model Actor model] and brings the experienced programmer to a previously unknown intimacy with pure [http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en Object Oriented Programming].
Line 184:	Line 185:
- '''Exercise 1: ''' Modify the procedure ''watch-server'' so that the same watcher process is re-used to watch all new ''test-server'' processes. -
Line 191:	Line 190:
- '''(unregister proc-id name)''': Removes the ''proc-id'' to ''name'' mapping from the system.	+ '''(unregister proc-id name)''': Removes the ''proc-id''-''name'' mapping.
Line 197:	Line 196:
- In distributed computing a program is split up into parts that run simultaneously on multiple computers communicating over a network. Spark process can be made to send and receive messages over the network. This does not need any extensive modification of existing code. A client process can send messages to a server process running on another machine using the ''send'' procedure itself. The server process on the other end of the network can use the same old ''receive'' procedure to know what the client is requesting. We need to use a new procedure, though. This is called ''remoting!'' and it starts the an internal TCP server that acts as a mediator between the distributed processes. The programmer need not worry about how the messages are packed, delivered and unpacked over the wire. All that is taken care of by the ''send'', ''receive'' and ''remoting!'' procedure calls. The ''trig-server'' we have written can serve clients in a networked environment, without any modification. Let us see how to start it as a server process:	+ In distributed computing a program is split up into parts that run simultaneously on multiple computers communicating over a network. Spark processes can be made to send and receive messages over the network. This does not require any extensive modification of existing code. A client process can send messages to a server process running on another machine using the ''send'' procedure itself. The server process on the other end of the network can use the same old ''receive'' procedure to get the request. We need to use a new procedure, though. This is called ''remoting!'' and it starts an internal TCP server that acts as a mediator between the distributed processes. The programmer need not worry about how the messages are packed, delivered and unpacked over the wire. All that is taken care of by the ''send'', ''receive'' and ''remoting!'' procedure calls. The ''trig-server'' we have written can serve clients in a networked environment, without any modification. Let us see how to start it as a server process:
Line 209:	Line 208:
- Now any client can send messages to the process "trig-server" by appending the machine name or IP to it. Here is a sample client that can interact with the remote trig-server:	+ Now clients can send messages to "trig-server" by appending the machine name or IP to it. Here is a sample client that can interact with the remote trig-server:
Line 231:	Line 230:
- Note the way we specify the remote process id appended with the machine name. We need to start the ''remoting'' service so as to get back the responses send by ''trig-server''. We start the client side remoting service of port 1445, because the default port 1383 is already bound by ''trig-server''. If the server and client processes are actually running on two machines, we need not change the port. Thus components in a Spark program can be distributed across a network with little additional programming effort. This is an important feature for a language that lives in this age of "cloud computing". One other language that offer this convenience is [http://erlang.org/ Erlang], which inspired and influenced the design of Spark concurrent objects. -	+ Note the way we specify the remote process id appended with the machine name. We need to start the ''remoting'' service so as to get back the responses send by ''trig-server''. We start the client side remoting service on port 1445, because the default port 1383 is already bound by ''trig-server''. If the server and client processes are actually running on two machines, we need not change the port. Thus components in a Spark program can be distributed across a network with very little additional programming effort. This is an important feature for a language that lives in the age of "cloud computing". One other language that offer this convenience is [http://erlang.org/ Erlang], which inspired and influenced the design of Spark concurrent objects.
Line 237:	Line 235:
- An asynchronous procedures can be used to get a time consuming computation done in the background. It is another way of creating processes without the messaging infrastructure. You define the computation as a procedure and invoke it with a call to ''async''. - - '''(async proc args-list callback-proc)''': ''proc'' is the procedure to be executed asynchronously. ''args-list'' is a list of arguments that will be passed to ''proc''. This should be null if ''proc'' does not take any arguments. ''callback-proc'' is a procedure that will be called once ''proc'' is done. ''called-proc'' will receive as it's argument the value that ''proc'' evaluates to. ''called-proc'' can be null.	+ An asynchronous procedures can be used to get a time consuming computation done in the background. It is another way of creating processes without the messaging infrastructure. The computation is defined as a procedure and invoke it with a call to ''async''. + + '''(async proc args-list callback-proc)''': ''proc'' is the procedure to be executed asynchronously. ''args-list'' is a list of arguments that will be passed to ''proc''. This should be null if ''proc'' does not take any arguments. ''callback-proc'' is a procedure that will be called once ''proc'' is done. ''callback-proc'' will receive as it's argument the value that ''proc'' evaluates to. ''callback-proc'' can be null.
Line 269:	Line 267:
- See the MzScheme documentation for more information on threads.	+ See the [MzScheme library reference "http://spark-scheme.wikispot.org/MzScheme_Library_Reference"] for more information on threads.
Line 273:	Line 271:
- The preferred paradigm for Spark is [http://www.defmacro.org/ramblings/fp.html Functional Programming]. ''(see the section on Concurrency)''. Spark is not a pure functional language. It means that there is nothing in the language that ''prevents'' you from sharing state across processes. If two processes modify a shared resource at the same time, that might lead to data corruption and incorrect program behavior. Spark provides the special form ''atomic'' to prevent a piece of code from being executed by two processes at the same time. If the portion of code that writes to the shared state is ''atomic'', it is guaranteed that it won't be modified by two processes at the same time.	+ The preferred paradigm for Spark is [http://www.defmacro.org/ramblings/fp.html Functional Programming]. ''(see the section on Concurrency)''. Spark is not a pure functional language. It means that there is nothing in the language that ''prevents'' you from sharing state across processes. If two processes modify a shared resource at the same time, that might lead to data corruption and incorrect program behavior. Spark provides the special form ''atomic'' to prevent a piece of code from being executed by two processes at the same time. If the portion of code that writes to the shared state is ''atomic'', it is guaranteed that it won't be modified by two processes simultaneously.

Concurrency

vijaymathew — 2009-06-21 12:30:55

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 6:	Line 6:
-

Concurrency

vijaymathew — 2009-06-20 20:58:02

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 1:	Line 1:
- next: ["Networking"] previous: ["Concurrency"] top: ["Programming spark" Contents]	+ next: ["Networking"] previous: ["Input/Output"] top: ["Programming spark" Contents]

Concurrency

vijaymathew — 2009-06-20 20:56:56

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 1:	Line 1:
-	+ next: ["Networking"] previous: ["Concurrency"] top: ["Programming spark" Contents]

Concurrency

vijaymathew — 2009-05-10 12:26:44

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 1:	Line 1:
- = Concurrency =	+

Concurrency

vijaymathew — 2009-05-03 13:29:54

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 1:	Line 1:
- == Concurrency ==	+ = Concurrency =

Concurrency

vijaymathew — 2009-05-02 13:38:27

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 198:	Line 198:
- In distributed computing a program is split up into parts that run simultaneously on multiple computers communicating over a network. Spark process can be made to send and recive messages over the network. This does not need any extensive modification of existing code. A client process can send messages to a server process running on another machine using the ''send'' procedure itself. The server process on the other end of the network can use the same old ''recive'' procedure to know what the client is requesting. We need to use a new procedure, though. This is called ''remoting!'' and it starts the an internal TCP server that acts as a mediator between the distributed processes. The programmer need not worry about how the messages are packed, delivered and unpacked over the wire. All that is taken care of by the ''send'', ''receive'' and ''remoting!'' procedure calls. The ''trig-server'' we have written can serve clients in a networked environment, without any modification. Let us see how to start it as a server process:	+ In distributed computing a program is split up into parts that run simultaneously on multiple computers communicating over a network. Spark process can be made to send and receive messages over the network. This does not need any extensive modification of existing code. A client process can send messages to a server process running on another machine using the ''send'' procedure itself. The server process on the other end of the network can use the same old ''receive'' procedure to know what the client is requesting. We need to use a new procedure, though. This is called ''remoting!'' and it starts the an internal TCP server that acts as a mediator between the distributed processes. The programmer need not worry about how the messages are packed, delivered and unpacked over the wire. All that is taken care of by the ''send'', ''receive'' and ''remoting!'' procedure calls. The ''trig-server'' we have written can serve clients in a networked environment, without any modification. Let us see how to start it as a server process:

Concurrency

vijaymathew — 2009-05-02 13:32:37

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 232:	Line 232:
- Note the way we specify the remote process id appended with the machine name. We need to start the ''remoting'' service so as to get back the responses send by ''trig-server''. We start the client side remoting service of port 1445, because the default port 1383 is already bound by ''trig-server''. If the server and client processes are actually running on two machines, we need not change the port.	+ Note the way we specify the remote process id appended with the machine name. We need to start the ''remoting'' service so as to get back the responses send by ''trig-server''. We start the client side remoting service of port 1445, because the default port 1383 is already bound by ''trig-server''. If the server and client processes are actually running on two machines, we need not change the port. Thus components in a Spark program can be distributed across a network with little additional programming effort. This is an important feature for a language that lives in this age of "cloud computing". One other language that offer this convenience is [http://erlang.org/ Erlang], which inspired and influenced the design of Spark concurrent objects.

Concurrency

vijaymathew — 2009-05-02 13:27:04

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 198:	Line 198:
- In distributed computing a program is split up into parts that run simultaneously on multiple computers communicating over a network. Spark process can be made to send and recive messages over the network. This does not need any extensive modification of existing code. A client process can send messages to a server process running on another machine using the ''send'' procedure itself. The server process on the other end of the network can use the same old ''recive'' procedure to know what the client is requesting. We need to use a new procedure, though. This is called ''remoting!'' and it starts the an internal TCP server that acts as a mediator between the distributed processes. The programmer need not worry about how the messages are packed, delivered and unpacked over the wire. All that is taken care of by the ''send'', ''receive'' and ''remoting!'' procedure calls.	+ In distributed computing a program is split up into parts that run simultaneously on multiple computers communicating over a network. Spark process can be made to send and recive messages over the network. This does not need any extensive modification of existing code. A client process can send messages to a server process running on another machine using the ''send'' procedure itself. The server process on the other end of the network can use the same old ''recive'' procedure to know what the client is requesting. We need to use a new procedure, though. This is called ''remoting!'' and it starts the an internal TCP server that acts as a mediator between the distributed processes. The programmer need not worry about how the messages are packed, delivered and unpacked over the wire. All that is taken care of by the ''send'', ''receive'' and ''remoting!'' procedure calls. The ''trig-server'' we have written can serve clients in a networked environment, without any modification. Let us see how to start it as a server process: + + {{{ + + > (load "trig-server.ss") + > (remoting!) + #<thread> + > (define pid (spawn trig-server)) + > (register pid "trig-server") + + }}} + + Now any client can send messages to the process "trig-server" by appending the machine name or IP to it. Here is a sample client that can interact with the remote trig-server: + + {{{ + + > (define (trig-client pid) + (let loop ((msg (receive pid))) + (printf "~a~n" msg) + (flush-output) + (loop (receive pid)))) + > (remoting! 1445) + #<thread> + > (define pid (spawn trig-client)) + > (register pid "trig-client") + > (send "trig-server@localhost" (list "trig-client@localhost:1445" 'sin 3.4)) + #t + -0.2555411020268312 + > (send "trig-server@localhost" (list "trig-client@localhost:1445" 'cos 1.2)) + #t + 0.3623577544766736 + + }}} + + Note the way we specify the remote process id appended with the machine name. We need to start the ''remoting'' service so as to get back the responses send by ''trig-server''. We start the client side remoting service of port 1445, because the default port 1383 is already bound by ''trig-server''. If the server and client processes are actually running on two machines, we need not change the port.

Concurrency

vijaymathew — 2009-05-02 13:03:20

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 198:	Line 198:
	+ In distributed computing a program is split up into parts that run simultaneously on multiple computers communicating over a network. Spark process can be made to send and recive messages over the network. This does not need any extensive modification of existing code. A client process can send messages to a server process running on another machine using the ''send'' procedure itself. The server process on the other end of the network can use the same old ''recive'' procedure to know what the client is requesting. We need to use a new procedure, though. This is called ''remoting!'' and it starts the an internal TCP server that acts as a mediator between the distributed processes. The programmer need not worry about how the messages are packed, delivered and unpacked over the wire. All that is taken care of by the ''send'', ''receive'' and ''remoting!'' procedure calls. +

Concurrency

vijaymathew — 2009-05-02 12:56:45

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 196:	Line 196:
	+ ==== Processes and distributed computing ==== + +

Concurrency

vijaymathew — 2009-05-02 12:55:09

(quick edit)

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 144:	Line 144:
- ==== Processes and fault tolerant ====	+ ==== Processes and fault tolerance ====

Concurrency

vijaymathew — 2009-05-02 12:39:18

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 3:	Line 3:
- -
Line 6:	Line 4:
-
Line 8:	Line 5:
-
Line 11:	Line 7:
- -
Line 14:	Line 8:
-
Line 17:	Line 10:
- -
Line 20:	Line 11:
- - -
Line 24:	Line 12:
-
Line 27:	Line 14:
- -
Line 31:	Line 16:
- -
Line 34:	Line 17:
- - -
Line 38:	Line 18:
- - -
Line 43:	Line 20:
- - - {{{ - -	+ {{{
Line 50:	Line 23:
- - -
Line 54:	Line 24:
-
Line 56:	Line 25:
-
Line 58:	Line 26:
-
Line 60:	Line 27:
-
Line 62:	Line 28:
-
Line 64:	Line 29:
- - ((_) handle-unexpected-message)))) - - - - }}} - -	+ (_ handle-unexpected-message)))) + + }}}
Line 75:	Line 35:
- - - {{{ - -	+ {{{
Line 83:	Line 39:
- -
Line 87:	Line 41:
- -
Line 90:	Line 42:
-
Line 92:	Line 43:
-
Line 94:	Line 44:
-
Line 96:	Line 45:
-
Line 98:	Line 46:
-
Line 100:	Line 47:
-
Line 102:	Line 48:
-
Line 104:	Line 49:
-
Line 106:	Line 50:
-
Line 108:	Line 51:
-
Line 110:	Line 52:
-
Line 112:	Line 53:
-
Line 114:	Line 54:
-
Line 116:	Line 55:
-
Line 118:	Line 56:
-
Line 120:	Line 57:
-	+ (newline))))) + + }}} + + To use the ''trig server'', load ''trig-server.ss'' into Spark and spawn a process with the procedure ''trig-server'' as it's callback. + + {{{ + + > (load "trig-server.ss") + > (define pid (spawn trig-server)) + + }}} + + Now we can send messages to the trigonometry object and have the results printed. As this object lives in it's own parallel world, we can go on with our business as it does the computations. + + {{{ + + > (send pid (list 'sin 3.4)) + sin of 3.4 is -0.2555411020268312 + > (send pid (list 'cos 2.1)) + cos of 2.1 is -0.5048461045998575 + > (send pid (list 'tan 3.5)) + tan of 3.5 is 0.3745856401585947 + > (send pid (list 'blah 7)) + Don't know the trif function (blah 7) + > (send pid 'exit) + Goodbye. + + }}} + + Let us extend the trig-server with a complete implementation of inter-process communication. The sending process should include it's process id as the first element of the message. ''trig-server'' will compute the result and send it back to that process. + + {{{ + + (import (match)) + + (define (trig-server pid) + (let loop ((message (receive pid))) + (cond + ((not (eq? message 'exit)) + (match message + ((sender-pid 'sin a) + (send sender-pid (sin a))) + ((sender-pid 'cos a) + (send sender-pid (cos a))) + ((sender-pid 'tan a) + (send sender-pid (tan a))) + (_ + (printf "Don't know the trig function ~a~n" message))) + (loop (receive pid))) + (else + (display "Goodbye.")
Line 125:	Line 113:
- - - To use the ''trig server'', load ''trig-server.ss'' into Spark and spawn a process with the procedure ''trig-server'' as it's callback. - - - - {{{ - -	+ Here is a client process that can interact with the ''trig-server''. It is wrapped up in a procedure that takes the server process id, the trig function and it's argument as it's parameters. Internally we spawn a new process that will send the request to the server get the response and print it. + + {{{ + + (define (trig-client server-pid func val) + (spawn + (lambda (pid) + (send server-pid (list pid func val)) + (printf "(~a ~a) = ~a" func val (receive pid)) + (flush-output)))) + + }}} + + To try our changed code, you need to load both trig-server.ss and trig-client.ss to the Spark environment. + + {{{
Line 136:	Line 131:
- - > (define pid (spawn trig-server)) - - - - }}} - - - - Now we can send messages to the trigonometry object and have the results printed. As this object lives in it's own parallel world, we can go on with our business as it does the computations. - - - - {{{ - - - - > (send pid (list 'sin 3.4)) - - sin of 3.4 is -0.2555411020268312 - - > (send pid (list 'cos 2.1)) - - cos of 2.1 is -0.5048461045998575 - - > (send pid (list 'tan 3.5)) - - tan of 3.5 is 0.3745856401585947 - - > (send pid (list 'blah 7)) - - Don't know the trif function (blah 7) - - > (send pid 'exit) - - Goodbye. - - - - }}} - - - - Let us extend the trig-server with a complete implementation of inter-process communication. The sending process should include it's process id as the first element of the message. ''trig-server'' will compute the result and send it back to that process. - - - - {{{ - - - - (import (match)) - - - - (define (trig-server pid) - - (let loop ((message (receive pid))) - - (cond - - ((not (eq? message 'exit)) - - (match message - - ((sender-pid 'sin a) - - (send sender-pid (sin a))) - - ((sender-pid 'cos a) - - (send sender-pid (cos a))) - - ((sender-pid 'tan a) - - (send sender-pid (tan a))) - - (_ - - (printf "Don't know the trig function ~a~n" message))) - - (loop (receive pid))) - - (else - - (display "Goodbye.") - - (newline))))) - - - - }}} - - - - Here is a client process that can interact with the ''trig-server''. It is wrapped up in a procedure that takes the server process id, the trig function and it's argument as it's parameters. Internally we spawn a new process that will send the request to the server get the response and print it. - - - - {{{ - - - - (define (trig-client server-pid func val) -	+ > (load "trig-client.ss") + > (define server-pid (spawn trig-server)) + > (trig-client server-pid 'sin 10) + 2 ;; pid of the new client process + (sin 10) = -0.5440211108893699 ;; result + > (trig-client server-pid 'cos 1.2) + 3 + (cos 1.2) = 0.3623577544766736 + + }}} + + With concurrent objects we have a powerful tool to model the real world in software. Like objects in the real world, Spark processes live and execute independently. They interact with other using messages. As they need not share memory, programs can be written without worrying about synchronization and locks. Spark's concurrent objects are an implementation of the [http://en.wikipedia.org/wiki/Actor_model Actor model] and brings the experienced programmer to a previously intimacy with pure [http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en Object Oriented Programming]. + + ==== Processes and fault tolerant ==== + + A system is ''fault tolerant'' if it can detect errors and repair itself. Spark process can have fault tolerance with the help of ''watcher'' processes. A ''watcher'' process is notified by the system when a ''watched'' process dies or exits. The following code snippet introduces the procedure ''watch'' that enables a process to keep an eye on another process: + + {{{ + + (define (test-server pid) + (let loop ((m (receive pid))) + (if (not (eq? m 'exit)) + (loop (receive pid))))) + + (define (watch-server server-pid)
Line 242:	Line 157:
-
Line 244:	Line 158:
- - (send server-pid (list pid func val)) - - (printf "(~a ~a) = ~a" func val (receive pid)) - - (flush-output)))) - - - - }}} - - - - To try our changed code, you need to load both trig-server.ss and trig-client.ss to the Spark environment. - - - - {{{ - - - - > (load "trig-server.ss") - - > (load "trig-client.ss") - - > (define server-pid (spawn trig-server)) - - > (trig-client server-pid 'sin 10) - - 2 ;; pid of the new client process - - (sin 10) = -0.5440211108893699 ;; result - - > (trig-client server-pid 'cos 1.2) - - 3 - - (cos 1.2) = 0.3623577544766736 - - - - }}} - - - - With concurrent objects we have a powerful tool to model the real world in software. Like objects in the real world, Spark processes live and execute independently. They interact with other using messages. As they need not share memory, programs can be written without worrying about synchronization and locks. Spark's concurrent objects are an implementation of the [http://en.wikipedia.org/wiki/Actor_model Actor model] and brings the experienced programmer to a previously intimacy with pure [http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en Object Oriented Programming]. - - - - ==== Processes and fault tolerant ==== - - - - A system is ''fault tolerant'' if it can detect errors and repair itself. Spark process can have fault tolerance with the help of ''watcher'' processes. A ''watcher'' process is notified by the system when a ''watched'' process dies or exits. The following code snippet introduces the procedure ''watch'' that enables a process to keep an eye on another process: - - - - {{{ - - - - (define (test-server pid) - - (let loop ((m (receive pid))) - - (if (not (eq? m 'exit)) - - (loop (receive pid))))) - - - - - - (define (watch-server server-pid) - - (spawn - - (lambda (pid) -
Line 324:	Line 159:
-
Line 326:	Line 160:
-
Line 328:	Line 161:
- - (if (eq? (car m) 'dead) -	+ (if (eq? (car m) 'dead)
Line 332:	Line 163:
-
Line 334:	Line 164:
-
Line 336:	Line 165:
-
Line 339:	Line 167:
- - - }}} - -	+ }}}
Line 347:	Line 171:
- - - {{{ - -	+ {{{
Line 354:	Line 174:
-
Line 356:	Line 175:
-
Line 358:	Line 176:
-
Line 360:	Line 177:
-
Line 362:	Line 178:
-
Line 364:	Line 179:
-
Line 366:	Line 180:
-
Line 368:	Line 181:
-
Line 371:	Line 183:
- - - }}} - -	+ }}}
Line 379:	Line 187:
- -
Line 383:	Line 189:
- -
Line 386:	Line 190:
-
Line 388:	Line 191:
-
Line 390:	Line 192:
-
Line 392:	Line 193:
-
Line 394:	Line 194:
-
Line 397:	Line 196:
- -
Line 400:	Line 197:
-
Line 403:	Line 199:
- -
Line 407:	Line 201:
- -
Line 411:	Line 203:
- - - {{{ - -	+ {{{
Line 418:	Line 206:
-
Line 420:	Line 207:
-
Line 422:	Line 208:
-
Line 424:	Line 209:
-
Line 426:	Line 210:
- - -
Line 430:	Line 211:
-
Line 432:	Line 212:
- - -
Line 436:	Line 213:
-
Line 438:	Line 214:
-
Line 441:	Line 216:
- - - }}} - -	+ }}}
Line 448:	Line 219:
-
Line 451:	Line 221:
- -
Line 455:	Line 223:
- - - {{{ - -	+ {{{
Line 462:	Line 226:
-
Line 464:	Line 227:
-
Line 467:	Line 229:
- - - }}} - -	+ }}}
Line 475:	Line 233:
- -
Line 479:	Line 235:
- -
Line 483:	Line 237:
- - - {{{ - - - - ;; BAD!! -	+ {{{ + + ;; Global state is BAD!!
Line 492:	Line 241:
- - -
Line 496:	Line 242:
-
Line 498:	Line 243:
-
Line 500:	Line 244:
- - -
Line 504:	Line 245:
-
Line 506:	Line 246:
-
Line 508:	Line 247:
-
Line 511:	Line 249:
- - - }}} - -	+ }}}

Concurrency

vijaymathew — 2009-05-01 12:29:50

Differences for Concurrency

Deletions are marked with - .	Additions are marked with +.
Line 1:	Line 1:
	+ == Concurrency == + + + + [#processes Concurrent objects or Processes] + + [#asyncprocs Asynchronous Procedures] + + [#threads Threads] + + + + [[Anchor(processes)]] + + === Concurrent objects or Processes === + + + + Spark allows several computations to execute simultaneously, possibly interacting with each other. In programming parlance this is known as multi-processing, multi-threading, concurrency etc. Programming languages usually depend on the host operating systems capabilities to implement concurrency. Spark has built-in concurrency. It provide multi-threading without any help from the underlying operating system. This has some important consequences: + + + + * Concurrent objects (or processes) behave the same on all operating systems. + + * They are not subject to any system imposed limitations. You can have as many concurrent objects as you want. + + + + To write concurrent programs, we need to become familiar with three new procedures: ''spawn'', ''send'' and ''receive''. + + + + '''(spawn proc)''': Creates a new process that evaluates the procedure ''proc''. The return value is an integer that identifies the process. It takes an optional arguments which can be used to initialize the state of the new process. + + + + '''(send pid)''': Sends a message to the process identified by ''pid''. Message sending is asynchronous. + + + + '''(receive pid)''': Receives a message from the message queue of the process identified by ''pid''. Calls to ''receive'' usually make use of the pattern matching facility provided by the ''match'' library and has the following coding pattern: + + + + {{{ + + + + (import (match)) + + + + (define (process-callback pid) + + (let ((msg (receive pid))) + + ;; Match the message against a set of patterns. + + (match msg + + ((pattern1) expressions1) + + ((pattern2) expressions2) + + ((_) handle-unexpected-message)))) + + + + }}} + + + + Let us try to get a better understanding of concurrent objects with the help of a simple example. Here we define an object that can act as background service for doing trigonometric calculations. It waits for messages in a loop. A message is packed as a list data structure with the first element identifying the trigonometric function to execute and the rest of the elements being it's arguments. When a message arrives, it is unpacked using the ''match'' procedure and an appropriate trigonometric function is executed and the result is displayed. If it receives the special message 'exit, the concurrent object kills itself. + + + + {{{ + + + + ;; file: trig-server.ss + + + + (import (match)) + + + + (define (trig-server pid) + + (let loop ((message (receive pid))) + + (cond + + ((not (eq? message 'exit)) + + (match message + + (('sin a) + + (printf "sin of ~a is ~a~n" a (sin a))) + + (('cos a) + + (printf "cos of ~a is ~a~n" a (cos a))) + + (('tan a) + + (printf "tan of ~a is ~a~n" a (tan a))) + + (_ + + (printf "Don't know the trig function ~a~n" message))) + + (loop (receive pid))) + + (else + + (display "Goodbye.") + + (newline))))) + + }}} + + + + To use the ''trig server'', load ''trig-server.ss'' into Spark and spawn a process with the procedure ''trig-server'' as it's callback. + + + + {{{ + + + + > (load "trig-server.ss") + + > (define pid (spawn trig-server)) + + + + }}} + + + + Now we can send messages to the trigonometry object and have the results printed. As this object lives in it's own parallel world, we can go on with our business as it does the computations. + + + + {{{ + + + + > (send pid (list 'sin 3.4)) + + sin of 3.4 is -0.2555411020268312 + + > (send pid (list 'cos 2.1)) + + cos of 2.1 is -0.5048461045998575 + + > (send pid (list 'tan 3.5)) + + tan of 3.5 is 0.3745856401585947 + + > (send pid (list 'blah 7)) + + Don't know the trif function (blah 7) + + > (send pid 'exit) + + Goodbye. + + + + }}} + + + + Let us extend the trig-server with a complete implementation of inter-process communication. The sending process should include it's process id as the first element of the message. ''trig-server'' will compute the result and send it back to that process. + + + + {{{ + + + + (import (match)) + + + + (define (trig-server pid) + + (let loop ((message (receive pid))) + + (cond + + ((not (eq? message 'exit)) + + (match message + + ((sender-pid 'sin a) + + (send sender-pid (sin a))) + + ((sender-pid 'cos a) + + (send sender-pid (cos a))) + + ((sender-pid 'tan a) + + (send sender-pid (tan a))) + + (_ + + (printf "Don't know the trig function ~a~n" message))) + + (loop (receive pid))) + + (else + + (display "Goodbye.") + + (newline))))) + + + + }}} + + + + Here is a client process that can interact with the ''trig-server''. It is wrapped up in a procedure that takes the server process id, the trig function and it's argument as it's parameters. Internally we spawn a new process that will send the request to the server get the response and print it. + + + + {{{ + + + + (define (trig-client server-pid func val) + + (spawn + + (lambda (pid) + + (send server-pid (list pid func val)) + + (printf "(~a ~a) = ~a" func val (receive pid)) + + (flush-output)))) + + + + }}} + + + + To try our changed code, you need to load both trig-server.ss and trig-client.ss to the Spark environment. + + + + {{{ + + + + > (load "trig-server.ss") + + > (load "trig-client.ss") + + > (define server-pid (spawn trig-server)) + + > (trig-client server-pid 'sin 10) + + 2 ;; pid of the new client process + + (sin 10) = -0.5440211108893699 ;; result + + > (trig-client server-pid 'cos 1.2) + + 3 + + (cos 1.2) = 0.3623577544766736 + + + + }}} + + + + With concurrent objects we have a powerful tool to model the real world in software. Like objects in the real world, Spark processes live and execute independently. They interact with other using messages. As they need not share memory, programs can be written without worrying about synchronization and locks. Spark's concurrent objects are an implementation of the [http://en.wikipedia.org/wiki/Actor_model Actor model] and brings the experienced programmer to a previously intimacy with pure [http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en Object Oriented Programming]. + + + + ==== Processes and fault tolerant ==== + + + + A system is ''fault tolerant'' if it can detect errors and repair itself. Spark process can have fault tolerance with the help of ''watcher'' processes. A ''watcher'' process is notified by the system when a ''watched'' process dies or exits. The following code snippet introduces the procedure ''watch'' that enables a process to keep an eye on another process: + + + + {{{ + + + + (define (test-server pid) + + (let loop ((m (receive pid))) + + (if (not (eq? m 'exit)) + + (loop (receive pid))))) + + + + + + (define (watch-server server-pid) + + (spawn + + (lambda (pid) + + (watch server-pid pid) + + (printf "~a watching ~a~n" pid server-pid) + + (let loop ((m (receive pid))) + + (if (eq? (car m) 'dead) + + (begin + + (printf "Process ~a is dead. Restarting it ...~n" (cdr m)) + + (watch-server (spawn test-server))) + + (loop (receive pid))))))) + + + + }}} + + + + The process represented by ''test-server'' can be brought under watch by passing it's proc-id to ''watch-server''. When it dies, it is restarted by the watcher. This is demonstrated in the following session: + + + + {{{ + + + + > (watch-server (spawn test-server)) + + 2 + + 2 watching 1 + + > (send 1 'exit) + + Process (1) is dead. Restarting it ... + + 4 watching 3 + + > (send 3 'exit) + + Process (3) is dead. Restarting it ... + + 6 watching 5 + + + + }}} + + + + '''Exercise 1: ''' Modify the procedure ''watch-server'' so that the same watcher process is re-used to watch all new ''test-server'' processes. + + + + Here are a few useful process utility procedures: + + + + '''(kill proc-id)''': Forcefully kills the process identified by ''proc-id''. + + '''(alive? proc-id)''': Returns #t if the process identified by ''proc-id'' is alive. + + '''(register proc-id name)''': Maps ''name'' to ''proc-id''. After registering the name, it can be used instead of ''proc-id'' in ''send'' calls. + + '''(unregister proc-id name)''': Removes the ''proc-id'' to ''name'' mapping from the system. + + '''(descriptor proc-id)''': Returns the thread descriptor object that the process internally uses. + + '''(message-channel proc-id)''': Returns the asynchronous message channel object that the process internally uses. + + + + [[Anchor(asyncprocs)]] + + === Asynchronous procedures === + + + + An asynchronous procedures can be used to get a time consuming computation done in the background. It is another way of creating processes without the messaging infrastructure. You define the computation as a procedure and invoke it with a call to ''async''. + + + + '''(async proc args-list callback-proc)''': ''proc'' is the procedure to be executed asynchronously. ''args-list'' is a list of arguments that will be passed to ''proc''. This should be null if ''proc'' does not take any arguments. ''callback-proc'' is a procedure that will be called once ''proc'' is done. ''called-proc'' will receive as it's argument the value that ''proc'' evaluates to. ''called-proc'' can be null. + + + + {{{ + + + + > (define (long-computation a b) + + ;; We simulate the long computation by + + ;; making the current thread of execution sleep for 2 seconds. + + (sleep 2) + + (+ a b)) + + + + > (define (done-callback result) + + (printf "long computation done. result is ~a~n" result)) + + + + > (async long-computation (list 10 20) done-callback) + + > + + long computation done. result is 30 + + + + }}} + + + + [[Anchor(threads)]] + + === Threads === + + + + If you have programmed in languages like Java or Python, you might have used ''threads'' to simulate concurrency. Spark too have threads. But unlike the aforementioned languages, Spark's multi-threading capabilities are not dependent on the host operating system. Threads is part of the Spark runtime itself. A new thread is created with a call to the ''thread'' procedure. It takes a procedure as it's argument, which will be execute in the new thread. The return value is a thread descriptor object. + + + + {{{ + + + + > (thread (lambda () (display "i am in a new thread!") (newline))) + + #<thread> + + i am in a new thread! + + + + }}} + + + + See the MzScheme documentation for more information on threads. + + + + ==== Atomic operations ==== + + + + The preferred paradigm for Spark is [http://www.defmacro.org/ramblings/fp.html Functional Programming]. ''(see the section on Concurrency)''. Spark is not a pure functional language. It means that there is nothing in the language that ''prevents'' you from sharing state across processes. If two processes modify a shared resource at the same time, that might lead to data corruption and incorrect program behavior. Spark provides the special form ''atomic'' to prevent a piece of code from being executed by two processes at the same time. If the portion of code that writes to the shared state is ''atomic'', it is guaranteed that it won't be modified by two processes at the same time. + + + + {{{ + + + + ;; BAD!! + + > (define global-state 0) + + + + > (define (modify-global-state) + + (atomic + + (set! global-state (add1 global-state)))) + + + + > (async modify-global-state) + + > (async modify-global-state) + + > global-state + + 2 + + + + }}} + + + + The atomic block in ''modify-global-state'' makes sure that all writes to ''global-state'' is serialized.