At first sight it would seem that a serial link must be inferior to a parallel one, because it can transmit less data on each clock tick. However, it is often the case that serial links can be clocked considerably faster than parallel links, and achieve a higher data rate. A number of factors allow serial to be clocked at a greater rate:

Clock skew between different channels is not an issue (for unclocked asynchronous serial communication links)
A serial connection requires fewer interconnecting cables (e.g. wires/fibres) and hence occupies less space. The extra space allows for better isolation of the channel from its surroundings
Crosstalk is less of an issue, because there are fewer conductors in proximity.
In many cases, serial is a better option because it is cheaper to implement. Many ICs have serial interfaces, as opposed to parallel ones, so that they have fewer pins and are therefore less expensive

When the Centronics parallel interface was first developed, the main peripheral was the printer. Since then, portable disk drives, tape backup drives, and CD-ROM players are among devices that have adopted the parallel interface. These new uses caused manufacturers to look at new ways to make the Centronics parallel interface better. In 1991, Lexmark, IBM, Texas instruments, and others met to discuss a standard that would offer more speed and bi-directional communication. Their effort and the sponsorship of the IEEE resulted in the IEEE 1284 committee. The IEEE 1284 standard was approved for release in March, 1994.

The IEEE 1284 standard specifies five modes of operation, each mode providing data transfer in either the forward direction (computer to peripheral), backward direction (peripheral to computer), or bi-directional (one direction at a time).

• Compatibility mode is the original Centronics parallel interface and intended for use with dot matrix printers and older laser printers. The compatibility mode can be combined with the nibble mode for bi-directional data transfer.
• Nibble mode allows data transfer back to the computer. The nibble mode uses the status lines to send 2 nibble s (4-bit units) of data to the computer in two data transfer cycles. This mode is best used with printers.
• Byte mode uses software driver s to disable the drivers that control the data lines in order for data to be sent from the printer to the computer. The data is sent at the same speed as when data is sent from the computer to the printer. One byte of data is transferred instead of the two data cycles required by the nibble mode.
• ECP mode (Enhanced Capability Port mode) is an advanced bi-directional mode for use with printers and scanner s. It allows data compression for image s, FIFO (first in, first out) for items in queue s, and high-speed, bi-directional communication. Data transfer occurs at two to four megabytes per second. An advanced feature of ECP is channel addressing . This is used for multifunction devices such as printer/fax/modem devices. For example, if a printer/fax/modem device needs to print and send data over the modem at the same time, the channel address software driver of the ECP mode assigns a new channel to the modem so that both devices can work simultaneously.
• EPP mode (Enhanced Parallel Port mode) was designed by Intel, Xircom, and Zenith Data Systems to provide a high-performance parallel interface that could also be used with the standard interface. EPP mode was adopted as part of the IEEE 1284 standard. The EPP mode uses data cycles that transfer data between the computer and the peripheral and address cycles that assign address, channel, or command information. This allows data transfer speeds of 500 kilobytes to 2 megabytes per second, depending on the speed of the slowest interface. The EPP mode is bi-directional. It is suited for network adapters, data acquisition, portable hard drives, and other devices that need speed.

The computer must determine what the capabilities of the attached peripheral are and which mode to utilize. The concept developed to determine these factors is called negotiation. Negotiation is a sequence of events on the parallel port interface that determines which IEEE 1284 modes the device can handle. An older device will not respond to the negotiation sequence and compatibility mode is selected to operate that device. A newer device will respond to the negotiation sequence and a more advanced mode can be set.

A fork bomb works by creating a large number of processes very quickly in order to saturate the available space in the list of processes kept by the computer’s operating system. If the process table becomes saturated, no new programs may start until another process terminates. Even if that happens, it is not likely that a useful program may be started since the instances of the bomb program will each attempt to take any newly-available slot themselves.
Not only do fork bombs use space in the process table each child process uses further processor-time and memory. As a result of this, the system and existing programs slow down and become much more unresponsive and difficult or even impossible to use.

fork bombs can occur by accident in the normal development of software. The development of an application that listens on a network socket and acts as the server in a Client-server system may well use an infinite loop and fork operation in a manner similar to one of the programs presented below. A trivial bug in the source of this kind of application could cause a fork bomb during testing.

How to Make a Fork Bomb Virus

This is how to make a fork bomb, open the terminal as superuser, and execute the following

: (){ :|:& };:

Understanding the above:

: ()      # define ':' -- whenever we say ':', do this:
{        # beginning of what to do when we say ':'
    :    # load another copy of the ':' function into memory...
    |    # ...and pipe its output to...
    :    # ...another copy of ':' function, which has to be loaded into memory
         # (therefore, ':|:' simply gets two copies of ':' loaded whenever ':' is called)
    &    # disown the functions -- if the first ':' is killed, all of the functions that it has started should NOT be auto-killed
}        # end of what to do when we say ':'
;        # Having defined ':', we should now...
:        # ...call ':', initiating a chain-reaction: each ':' will start two more.

 
CLIENT RCS

head 1.3;
access;
symbols;
locks; strict;
comment @ * @;

1.3
date 2013.12.30.07.44.46; author root; state Exp;
branches;
next 1.2;

1.2
date 2013.12.29.10.18.44; author root; state Exp;
branches;
next 1.1;

1.1
date 2013.12.29.10.06.57; author root; state Exp;
branches;
next ;

desc
@Client program
@

1.3
log
@in this version client will connect to server and will write a character on socket, and after procesing from server, it will read and display the character from socket.
@

Advantages

In semaphores there is no spinning, hence no waste of resources due to no busy waiting. That is because threads intending to access the critical section are queued. And could access the priority section when the are de-queued, which is done by the semaphore implementation itself, hence, unnecessary CPU time is not spent on checking if a condition is satisfied to allow the thread to access the critical section.

Semaphores permit more than one thread to access the critical section, in contrast to alternative solution of synchronization like monitors, which follow the mutual exclusion principle strictly. Hence, semaphores allow flexible resource management.
Finally, semaphores are machine independent, as they are implemented in the machine independent code of the microkernel services.

Disadvantages

Problem 1: Programming using Semaphores makes life harder as utmost care must be taken to ensure Ps and Vs are inserted correspondingly and in the correct order so that mutual exclusion and deadlocks are prevented. In addition, it is difficult to produce a structured layout for a program as the Ps and Vs are scattered all over the place. So the modularity is lost. Semaphores are quite impractical when it comes to large scale use.

Problem 2: Semaphores involve a queue in its implementation. For a FIFO queue, there is a high probability for a priority inversion to take place wherein a high priority process which came a bit later might just have to wait when a low priority one is in the critical section. For example, consider a case when a new smoker joins and is desperate to smoke. What if the agent who handles the distribution of the ingredients follows a FIFO queue (wherein the desperate smoker is last according to FIFO) and chooses the ingredients apt for another smoker who would rather wait some more time for a next puff?