BB kffig

-Most scripting languages (Scheme in the obvious exception) do not require variables to be declared•Perl and JavaScript permit optional declarations  sort of compiler-checked documentation•Perl can be run in a mode (use strict ‘vars’) that requires declarations
-With or without declarations, most scripting languages use dynamic typing•The interpreter can perform type checking at run time, or coerce values when appropriate •TCLis unusual in that all values-even lists-are represented internally as strings-Nesting and scoping conventions vary quite a bit•Scheme, Python,JavaScript provide the classic combination of nested subroutines and static (lexical) scope •Tcl allows subroutines to nest, but uses dynamic scope•Named subroutines (methods) do not nest in PHP or Ruby•Perl and Ruby join Scheme, Python, and JavaScript in providing first class anonymous local subroutines•Nested blocks are statically scoped in Perl•In Ruby, they are part of the named scope in which they appear•Scheme, Perl, Python provide for variables captured in closures PHP and the major glue languages (Perl, Tel, Python, Ruby) all have sophisticaten amespace rules mechanisms for information hiding and the selective import of names from separate module•In Perl, all variables are global unless otherwise specified. o In PHP, local unless explicitly imported•Ruby has only two levels: $foo is global, foo is local; foo is instance of current object,and @@foo is instance variable of current object’s class.

Naming Communication Partners:To send or receive a message, one must generally specify where to send it to, or where to receive it from-communication partners need names for (or references to) one another. Names may refer directly to a thread or process. Alternatively, they may refer to an entry or port of a module, or to some sort of socket or channel abstraction.The first naming option-addressing messages to processes-appears in Hoare’s original CSP proposal, and in PVM and MPI. Each PVM or MPI process has a unique id (an integer), and each send or receive operation specifies the id of the communication partner.#Sending:

One of the most important issues to be addressed when designing a send operation is the extent to which it may block the caller: once a thread has initiated a send operation, when is it allowed to continue execution? Blocking can serve at least three purposes:1.Resource Management 2.Failure semantics3.return parameters #Receiving

Probably the most important dimension on which to categorize mechanisms for receiving messages is the distinction between explicit receive operations and the implicit receipt. The SR language provides an implicit receipt.

•Before the study of synchronization, let us understand the common nomenclature used for different activities in the computer system.Concurrent tasks: If not explicitly stated otherwise, the term task will be used to refer to a concurrent unit of execution such as a thread or a process.Atomic operations: In concurrent programming, an operation (or set of operations) is atomic if it appears to the rest of the system to occur at once without being interrupted. Other words used synonymously with atomic are: linearizable, indivisible or uninterruptible.Non-atomic operations: Incrementing and decrementing a variable are examples of non-atomic operations. The following C expression, X++; is translated by the compiler to three instructions:

•load X from memory into a CPU register. 
•increment X and save result in a CPU register.
•store result back to memory.Race condition: A race condition or race hazard is the behaviour of an electronic, software or other system where the output is dependent on the sequence or timing of other uncontrollable events. It becomes a bug when events do not happen in the intended order. The term originates with the idea of two signals racing each other to influence the output first.Data race: A data race occurs when two instructions from different threads access the same memory location and at least one of these accesses is a write and there is no synchronization that is mandating any particular order among these accesses.

Critical section : Concurrent accesses to shared resources can lead to unexpected or erroneous behavior, so parts of the program where the shared resource is accessed are protected. This protected section is the critical section or critical region. Typically, the critical section accesses a shared resource, such as a data structure, a peripheral device, or a network connection, that would not operate correctly in the context of multiple concurrent accesses.

Mutual exclusion (mutex): In computer science, mutual exclusion is a property of concurrency control, which is instituted for the purpose of preventing race conditions; it is the requirement that one thread of execution never enter its critical section at the same time that another concurrent thread of execution enters its own critical section. Often the word mutex is used as a short form of mutual exclusion.

In the message-passing model, concurrent modules interact by sending messages to each other through a communication channel. Modules send-off messages, and incoming messages to each module are queued up for handling. Examples include: •A and B might be two computers in a network, communicating by network connections.•A and B might be a web browser and a web server – A opens a connection to B, saks for a web page, and B sends the web page data back to A. A and B might be an instant messaging client and server.•A and B might be two programs running on the same computer whose input and output have been connected by a pipe, like is | grep typed into a command prompt.