The document discusses interprocess communication (IPC) methodologies such as shared memory and message passing, highlighting their advantages and use cases. It covers the client-server model and process management, including concepts like process creation, process identifiers, and system calls like fork() and exec(). The document also outlines a simple compiler implementation in Java for a specified grammar, detailing aspects of lexical analysis and syntax parsing.

1. 1-Information sharing
2-Computation speedup
3-Modularity
4-Convenience
5-allows exchanged data and informations
Two IPC Models
1. Shared memory- is an OS provided abstraction which allows
a memory region to be simultaneously accessed by multiple
programs with an intent to provide communication among them.
One process will create an area in RAM which other processes
can accessed
2. Message passing - is a form of communication used in
interprocess communication. Communication is made by the
sending of messages to recipients. Each process should be able
to name the other processes. The producer typically uses send()
system call to send messages, and the consumer uses
receive()system call to receive messages
Shared memory
Faster than message passing
After establishing shared memory, treated as routine memory
accesses
Message passing
Useful for exchanging smaller amounts of data

2. Easy to implement, but more time-consuming task of kernel
intervention
Bounded-Buffer Problem Producer Process
do {
...
produce an item in nextp
...
wait(empty);
wait(mutex);
...
add nextp to buffer
...
signal(mutex);
signal(full);
} while (true);
Bounded-Buffer Problem Consumer Process
do {
wait(full);
wait(mutex);
...
remove an item from buffer to nextc
...
signal(mutex);
signal(empty);
...
consume the item in nextc
...
} while (true);

3. client-server model, the client sends out requests to the
server, and the server does some processing with the request(s)
received, and returns a reply (or replies)to the client.
Since Socket can be described as end-points for communication.
we could imagine the client and server hosts being connected by
a pipe through which data-flow takes place.
1-sockets use a client-server while Server waits for incoming
client requests by listening to a specified port.
2-After receiving a request, the server accepts a connection
from the client socket to complete the connection
3-then Remote procedure call (RPC) abstracts procedure call
mechanism for use between systems with network connections
4-and pipes acts as a conduit allowing two processes to
communicate
A process is different than a program
- Program is static code and static data
- Process is Dynamic instance of code and data
-Program becomes process when executable file loaded into
memory
No one-to-one mapping between programs and processes
-can have multiple processes of the same program
-one program can invoke multiple process
Execution of program started via GUI mouse clicks and
command line entry of its name
The process state transition

4. As a process executes, The process is being created, then The
process is waiting to be assigned to a processor therefore,
Instructions are being executed then The process is waiting for
some event to occur,thereafter The process has finished
execution
Parent process creates children processes, which, in turn create
other processes, forming a tree of processes
The new child process is a complete copy of the executing
program
Generally, process identified and managed via a process
identifier (pid)
getpid ()
The new child process has a new process identifier.
fork () returns the child’s PID to the parent, 0 to the child.
When calling exec (), all data in the original program is lost,
and replaced with a running copy of the new program:
Overlaying
UNIX examples
fork () system call creates new process
exec () system call used after a fork() to replace the process’
memory space with a new program

5. /**
* Programming Languages: Implementation and Design.
*
* A Simple Compiler Adapted from Sebesta (2010) by Josh
Dehlinger further modified by Adam Conover
* (2012-2015)
*
* A simple compiler used for the simple English grammar in
Section 2.2 of Adam Brooks Weber's
* "Modern Programming Languages" book. Parts of this code
was adapted from Robert Sebesta's
* "Concepts of Programming Languages".
*
* This compiler assumes that the source file containing the
sentences to parse is provided as the
* first runtime argument. Within the source file, the compiler
assumes that each sentence to parse
* is provided on its own line.

6. *
* NOTE: A "real" compiler would more likely treat an entire
file as a single stream of input,
* rather than each line being an independent input stream.
*/
import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;
public class Compiler {
/**
* It is assumed that the first argument provided is the name
of the source file that is to be
* "compiled".
*/
public static void main(String[] args) throws IOException {
//args = new String[]{"<some hard coded path for
testing>"};
//args = new

7. String[]{"D:Version_Controlled_SVN_NewtonCOS420J
avaParserSampleinput.txt"};
if (args.length < 1) {
System.out.println("Need a filename!");
} else {
// Java 7 "try-with-resource" to create the file input
buffer.
try (BufferedReader br = new BufferedReader(new
FileReader(args[0]))) {
// Create the new lexer.
LexicalAnalyzer lexer = new LexicalAnalyzer();
// Start lexing and parsing.
processFile(lexer, br);
}
}
}
/**

8. * Reads each line of the input file and invokes the lexer and
parser for each.
*/
static void processFile(LexicalAnalyzer lexer,
BufferedReader br) throws IOException {
String sourceLine;
// Read each line in the source file to be compiled as a
unique sentence
// to check against the grammar.
while ((sourceLine = br.readLine()) != null) {
// Ignore empty lines and comments.
if (sourceLine.trim().length() <= 0) {
continue;
}
if (sourceLine.trim().startsWith("#")) {
System.out.println("Comment: " +
sourceLine.substring(1).trim());
continue;
}

9. // Create a new syntax analyzer over the provided lexer.
SyntaxAnalyzer parser = new SyntaxAnalyzer(lexer);
// Parse the given sentence against the given grammar.
We assume that the
// sentence, <S>, production is the start state.
try {
// Start the lexer...
lexer.start(sourceLine);
// Start the parser...
parser.analyze();
// No exceptions, so we must be good!
System.out.printf("The sentence '%s' follows the
BNF grammar.%n", sourceLine);
} catch (ParseException error) {
// If a syntax error was found, print that the sentence

10. does not follow the grammar.
System.out.printf("SYNTAX ERROR while
processing: '%s'%n", sourceLine);
System.out.printf("ERROR MSG: %s%n",
error.getErrMsg());
}
System.out.println("------------------------------------------
-----------------");
}
}
}
Assume we start with a simple "sentence" grammar as follows:
<S> ::= <NP><V><NP>
<NP> ::= <A> <N>
<V> ::= loves | hates | eats
<A> ::= a | the
<N> ::= dog | cat | rat
Part A:
Show the BNF above with the following additional grammar
elements:
· Adjectives: (0 or more Adjectives separated by commas may
precede any Noun. A comma may or may not be preceded by a
space.)

11. · furry
· fast
· slow
· delicious
· Adverbs: (0 or 1 Adverb may precede any Verb)
· quickly
· secretly
· Conjunctions: (0 or more may appear in any sentence
· and
· or
· Sentence terminator (The terminator may or may not be
preceded by a space.)
· . (a single period)
· ! (a single period)
·
Part B:
Show/Draw the syntax diagrams for each of the grammar
elements above. Hyperlink reference not valid.
Part C:
Show the parse trees (which can be generated in ANTLRWorks)
for each of the following sentences:
Examples of SYNTACTICALLY VALID Input Strings:
a dog loves the cat.
the cat eats the slow rat and the slow , furry dog secretly hates
the cat and a dog loves the rat !
Examples of SYNTACTICALLY INVALID Input Strings (where
do they fail):
a dog barks at the cat.
the fast furry cat eats quickly
NOTE: You can generate the full parse trees from
ANTLRWorks (as can be done with the attached sample for the
base grammar) or simply draw out the cooresponding AST's
(Abstract Syntax Trees) "by hand" on paper or with a simple
drawing tool. The point of this is to have something that you
can then verify against the parse trees generated by your own

12. code (in the next part).
Part D:
Modify the (attached) sample code to accept valid sentences
based upon the newly defined grammar above. The parser
should also "reject" invalid sentences with a descriptive error
message. Note that the program should still accept a filename
from the "Command Line" as illustrated in the example. Please
no HARD-CODED file paths in the source.