The POSIX thread libraries are a standards based thread API for C/C++. It allows one to spawn a new concurrent process flow. It is most effective on multi-processor or multi-core systems where the process flow can be scheduled to run on another processor thus gaining speed through parallel or distributed processing. Threads require less overhead than “forking” or spawning a new process because the system does not initialize a new system virtual memory space and environment for the process. While most effective on a multiprocessor system, gains are also found on uniprocessor systems which exploit latency in I/O and other system functions which may halt process execution. (One thread may execute while another is waiting for I/O or some other system latency.) Parallel programming technologies such as MPI and PVM are used in a distributed computing environment while threads are limited to a single computer system. All threads within a process share the same address space. A thread is spawned by defining a function and its arguments which will be processed in the thread. The purpose of using the POSIX thread library in your software is to execute software faster.

void *thread_function(void *arg);
char mssg[]=”hi there”;
int main()
{
pthread_t var[20];
void *thrd_rslt;
int ret = pthread_create(&var[20],NULL,thread_function,(void *)mssg);
if(ret!=0)
{
perror(“creation failed”);
//              exit(EXIT_FAILURE);
return -1;
}
printf(” i got it……\n”);
printf(“thred created……\n”);
printf(“waiting for thread to finish………>>>>>>>\n”);
ret=pthread_join(var[20],&thrd_rslt);
if(ret!=0)
{
perror(“joining failed”);
//exit(EXIT_FAILURE);
return -1;
}
printf(“thread join returned %s\n”,(char *)thrd_rslt);
printf(“now message is %s\n”,mssg);
//exit(EXIT_SUCCESS);
return 0;
}
void *thread_function(void *arg)
{
printf(“thread function is running with arg %s\n”,(char*)arg);
sleep(2);
strcpy(mssg,”bye”);
pthread_exit(“thanks for cpu time>>>>>>>\n”);
}

We already know what drivers are, and why we need them. What is so special about character drivers? If we write drivers for byte-oriented operations (or, in C lingo, character-oriented operations), then we refer to them as character drivers. Since the majority of devices are byte-oriented, the majority of device drivers are character device drivers.

Take, for example, serial drivers, audio drivers, video drivers, camera drivers, and basic I/O drivers. In fact, all device drivers that are neither storage nor network device drivers are some type of a character driver. Let’s look into the commonalities of these character drivers, and how Shweta wrote one of them.

The complete connection

As shown in Figure 1, for any user-space application to operate on a byte-oriented device (in hardware space), it should use the corresponding character device driver (in kernel space). Character driver usage is done through the corresponding character device file(s), linked to it through the virtual file system (VFS). What this means is that an application does the usual file operations on the character device file. Those operations are translated to the corresponding functions in the linked character device driver by the VFS. Those functions then do the final low-level access to the actual device to achieve the desired results.

Note that though the application does the usual file operations, their outcome may not be the usual ones. Rather, they would be as driven by the corresponding functions in the device driver. For example, a write followed by a read may not fetch what has just been written to the character device file, unlike for regular files. Remember that this is the usual expected behaviour for device files. Let’s take an audio device file as an example. What we write into it is the audio data we want to play back, say through a speaker. However, the read would get us audio data that we are recording, say through a microphone. The recorded data need not be the played-back data.

In this complete connection from the application to the device, there are four major entities involved:

1. Application
2. Character device file
3. Character device driver
4. Character device

The interesting thing is that all of these can exist independently on a system, without the other being present. The mere existence of these on a system doesn’t mean they are linked to form the complete connection. Rather, they need to be explicitly connected. An application gets connected to a device file by invoking the open system call on the device file.

Device file(s) are linked to the device driver by specific registrations done by the driver. The driver is linked to a device by its device-specific low-level operations. Thus we form the complete connection. With this, note that the character device file is not the actual device, but just a place-holder for the actual device.

Major and minor numbers

The connection between the application and the device file is based on the name of the device file. However, the connection between the device file and the device driver is based on the number of the device file, not the name. This allows a user-space application to have any name for the device file, and enables the kernel-space to have a trivial index-based linkage between the device file and the device driver. This device file number is more commonly referred to as the <major, minor> pair, or the major and minor numbers of the device file.

Earlier (till kernel 2.4), one major number was for one driver, and the minor number used to represent the sub-functionalities of the driver. With kernel 2.6, this distinction is no longer mandatory; there could be multiple drivers under the same major number, but obviously, with different minor number ranges.

However, this is more common with the non-reserved major numbers, and standard major numbers are typically preserved for single drivers. For example, 4 for serial interfaces, 13 for mice, 14 for audio devices, and so on. The following command would list the various character device files on your system:

SYSTEM CALL: pipe();

PROTOTYPE: int pipe( int fd[2] );
RETURNS: 0 on success
-1 on error: errno = EMFILE (no free descriptors)
EMFILE (system file table is full)
EFAULT (fd array is not valid)

NOTES: fd[0] is set up for reading, fd[1] is set up for writing

The first integer in the array (element 0) is set up and opened for reading, while the second integer (element 1) is set up and opened for writing. Visually speaking, the output of fd1 becomes the input for fd0. Once again, all data traveling through the pipe moves through the kernel.

#include
#include
#include

main()
{
int fd[2];

pipe(fd);
.
.
}

Remember that an array name in C decays into a pointer to its first member. Above, fd is equivalent to &fd[0]. Once we have established the pipeline, we then fork our new child process:

#include
#include
#include

main()
{
int fd[2];
pid_t childpid;

pipe(fd);

if((childpid = fork()) == -1)
{
perror(“fork”);
exit(1);
}
.
.
}

If the parent wants to receive data from the child, it should close fd1, and the child should close fd0. If the parent wants to send data to the child, it should close fd0, and the child should close fd1. Since descriptors are shared between the parent and child, we should always be sure to close the end of pipe we aren’t concerned with. On a technical note, the EOF will never be returned if the unnecessary ends of the pipe are not explicitly closed.

#include
#include
#include

main()
{
int fd[2];
pid_t childpid;

pipe(fd);

if((childpid = fork()) == -1)
{
perror(“fork”);
exit(1);
}

if(childpid == 0)
{
/* Child process closes up input side of pipe */
close(fd[0]);
}
else
{
/* Parent process closes up output side of pipe */
close(fd[1]);
}
.
.
}

Name of the function is globaly decleared therefore it can be accesed from anywhere in the program.
Use of functions reduce the complexity of the c program and it gives the return type, function name, passing arguments.All the c program have a function ‘main’.

STRUCTURE OF FUNCTION–-

There are three parts of function.

1.FUNCTION PROTOTYPE
2.FUNCTION CALL
3.FUNCTION DEFINITION

FUNCTION PROTOTYPE–>Function prototype gives the return type ,function name and the data type of the arguments that is to be passed.

Return_type Function_name(data type of arguments);
eg- int fun_name(int , int);
Note-In prototype only the data type is define.And the order of the arguement will do matter.
and the prototype will be define globally.

FUNCTION CALL-> Function call will be define in main.In the call function argument will be pass, according to the reqirment of the program.It will declear the element which is about to pass.
And if we want to return a value from defination then store the value in different variable.
There are tthree different way to passing an argument.
a.Pass by value
b.Pass by reference
c.Passing a array
=>In pass by value:-value of deta type will be pass to a function.
=>In pass by reference:-Address of the data type will be pass.
=>In pass by array:-Name and the size of array will be pass to afunction.

eg- function_name(i , j);

//where iand j are the variables,here when we pass the address of the i and j ,then it will be the pass by reference.

function_name(size , name of the array); // pass by array

FUNCTION DEFINITION–>

it gives the return type ,function name and the passing argument with the data type and the body of the difinition is—-

return_type function _name(passed argument with their data types)
{
statements
—————-
}