EmbLogic's Blog

implementation of stack using pointers

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

1.1
date 2014.03.29.11.10.17; author emblogic; state Exp;
branches;
next ;

desc
@this is a program of stack implementation using poimters
@

1.1
log
@Initial revision
@
text
@#include”header.h”
int main()
{
void *stack;
int ch,top=-1;
do
{
printf(“1: push\n”);
printf(“2: pop\n”);
printf(“3: display\n”);
printf(“enter your choice\n”);
scanf(“%d”,&ch);
switch(ch)
{
case 1:
push(&stack,&top);
break;
case 2:
pop(&stack,&top);
break;
case 3:
display(&stack,&top);
break;
defautl:
printf(“wrong choice\n”);
}
}while(ch != 4);
}

@
@#include”header.h”
int push(void **astack,int *atop)
{
static char ch=1;

if( *atop >= MAX-1)
{
printf(“stack overflow\n”);
return -1;
}
if( *atop < 0)
{
*astack=(char *)malloc(1);
(*atop)++;
*(char *)(*astack + *atop)=ch;
ch++;
return 0;
}
(*atop)++;
*astack=(char *)realloc(*astack, (*atop)+1);
*(char *)(*astack + *atop)=ch;
ch++;

return 0;
}
int pop(void **astack,int *atop)
{
if(*atop=0; i–)
{
printf(“the element at loc %d is = %d\n”,i, *(char *)(*astack + i));
}
}

@

Posted in Uncategorized | Leave a comment

program of implementation of stacks.

RCS file: fun.c,v
Working file: fun.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
this is the program of implementation of stacks using pointer.
—————————-
revision 1.1
date: 2014/03/29 11:06:26; author: root; state: Exp;
Initial revision
=============================================================================

RCS file: main.c,v
Working file: main.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
—————————-
revision 1.1
date: 2014/03/29 11:06:26; author: root; state: Exp;
Initial revision

Posted in Uncategorized | Leave a comment

program of reversing link list.

rlog: RCS/vim,v: No such file or directory

RCS file: llrev.c,v
Working file: llrev.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
this is the program of reversing link list using three pointer.
—————————-
revision 1.1
date: 2014/03/29 11:02:35; author: root; state: Exp;
Initial revision

Posted in Uncategorized | Leave a comment

Message Queues imlementation

RCS file: sender.c,v
Working file: sender.c
head: 1.1
branch:
locks: strict
	root: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;	selected revisions: 1
description:
  • Implemented Message Queue using msgget(),msgsnd(),and msgrcv() functions.
  • message queue is half duplex mode of communication.
  • That means ,only we can write data or read data at one time.
  • message queues are better than fifos because we can send or recieve data to a particular process using message type variable.
----------------------------
revision 1.1	locked by: root;
date: 2014/03/20 17:45:25;  author: root;  state: Exp;
Initial revision

Message Queue:
Message queues are used in INTER_PROCESS COMMUNICATION to transfer data between unrelated .
Posted in Data Structures with C | Tagged | Leave a comment

character driver proc with kernel 3.12

Add two header proc_fs.h, seq_file.h
Initialize the proc by proc_create() and remove by remove_proc_entry()
Map the file operation in structure
write open proc function and give entry

Posted in Character Driver | Leave a comment

Circular Queue

Figure of circular queue

R->Rear

F->Front

Initially rear=front=0

Circular queue is as shown in figure it is like a array size in which element are from 0 to (n-1) if array is of length n it is divided into nodes of equal size and and equal to number of size of queue.In this insertion is carried out from the rear node and deletion take place from front node.when we insert number rear moves to rear+1 and when we delete any element front moves to front-1 and when queue is filled the rear+1=front.

Posted in Uncategorized | Leave a comment

ipc using fifo

2 RCS file: fifoserver.c,v
3 Working file: fifoserver.c
4 head: 1.3
5 branch:
6 locks: strict
7 access list:
8 symbolic names:
9 keyword substitution: kv
10 total revisions: 3;     selected revisions: 3
11 description:
12 client1 had open the fifo and writes the data and then server had read the data.
13 —————————-
14 revision 1.3
15 date: 2014/03/28 10:47:55;  author: root;  state: Exp;  lines: +10 -2
16 data is read by server from three requesting clients
17 —————————-
18 revision 1.2
19 date: 2014/03/28 09:46:01;  author: root;  state: Exp;  lines: +20 -2
20 data is read in server from two requesting clients
21 —————————-
22 revision 1.1
23 date: 2014/03/28 06:18:35;  author: root;  state: Exp;
24 Initial revision
25 =============================================================================

Posted in Project 03: Client Server Communication using Linux and IPC | Leave a comment

IPC

head 1.5;
access;
symbols;
locks
arjun:1.5; strict;
comment @ * @;

1.5
date 2014.03.28.17.04.43; author arjun; state Exp;
branches;
next 1.4;

1.4
date 2014.03.27.15.56.06; author arjun; state Exp;
branches;
next 1.3;

1.3
date 2014.03.27.06.05.30; author arjun; state Exp;
branches;
next 1.2;

1.2
date 2014.03.25.08.06.10; author arjun; state Exp;
branches;
next 1.1;

1.1
date 2014.03.25.05.16.16; author arjun; state Exp;
branches;
next ;

desc
@we are using 2 pipe for requesting client and same for processing client
but not use switch case in server.
@

1.5
log
@now we are able to collect the data at server from processing client
@

Posted in Uncategorized | Leave a comment

P-THREAD

 

 An overview of Pthreads

 Introduction

Thread: A Thread is a ‘Light Weight Process’. A thread is a stream of instructions that can be scheduled as an independent unit. A thread exists within a process, and uses the process resources. Since threads are very small compared with processes, thread creation is relatively cheap in terms of CPU costs. As processes require their own resource bundle, and threads share resources, threads are likewise memory frugal. There can be multiple threads within a process. Multithreaded programs may have several threads running through different code paths “simultaneously”.

Shared Memory Programming

Shared-memory systems typically provide both static and dynamic process creation. That is, processes can be created at the beginning of program execution by a directive to the operating system, or they can be created during the execution of the program. The best-known dynamic process creation function is fork. A typical implementation will allow a process to start another, or child, process by a fork. Three processes typically manage coordinating among processes in shared memory programs. The starting, or a parent, process can wait for the termination of the child process by calling join. The second prevents processes from improperly accessing shared resources. The third provides a means for synchronizing the processes.

The shared-memory model is similar to the data-parallel model. It has a single address (global naming) space. It is similar to the message passing model in that it is multithreading and synchronous. However, data reside in a single, shared address space, thus does not have to be explicitly allocated. Workload can be either explicitly or implicitly allocated. Communication is done implicitly through shared reads and writes of variables. However, synchronization is explicit.

Shared variable programs are multi threaded and asynchronous, require explicit synchronizations to maintain correct execution order among the processes. Parallel programming based on the shared memory model has not progressed as much as message passing parallel programming. An indicator is the lack of a widely accepted standard such as MPI or PVM for message passing. The current situation is that shared-memory programs are written in a platform specific language for multiprocessors (mostly SMPs and PVPs). Such programs are not portable even among multiprocessors, not to mention multicomputers (MPPs and clusters). Three platform independent shared memory programming models are X3H5, Pthreads, and OpenMP.

 Pthreads:

The Pthreads library is a POSIX C API thread library that has standardized functions for using threads across different platforms. Historically, hardware vendors have implemented their own proprietary versions of threads. These implementations differed substantially from each other making it difficult for programmers to develop portable threaded applications. In order to take full advantage of the capabilities provided by threads, a standardized programming interface was required. For UNIX systems, this interface has been specified by the IEEE POSIX 1003.1c standard (1995). Implementations that adhere to this standard are referred to as POSIX threads, or Pthreads. Most hardware vendors now offer Pthreads in addition to their proprietary API’s. Pthreads are defined as a set of C language programming types and procedure calls. Vendors usually provide a Pthreads implementation in the form of a header/include file and a library that you link with your program.

Pthreads

  • The primary motivation for using Pthreads is to realize potential program performance gains.
  • When compared to the cost of creating and managing a process, a thread can be created with much less operating system overhead. Managing threads requires fewer system resources than managing processes.
  • All threads within a process share the same address space. Inter-thread communication is more efficient and in many cases, easier to use than inter-process communication.
  • Threaded applications offer potential performance gains and practical advantages over non-threaded applications in several other ways:
  • Overlapping CPU work with I/O: For example, a program may have sections where it is performing a long I/O operation. While one thread is waiting for an I/O system call to complete, other threads can perform CPU intensive work.
  • Priority/real-time scheduling: tasks that are more important can be scheduled to supersede or interrupt lower priority tasks.
  • Asynchronous event handling: tasks that service events of indeterminate frequency and duration can be interleaved. For example, a web server can both transfer data from previous requests and manage the arrival of new requests.
  • Multi-threaded applications will work on a uni-processor system; yet naturally take advantage of a multiprocessor system, without recompiling.
  • In a multiprocessor environment, the most important reason for using Pthreads is to take advantage of potential parallelism. This will be the focus of the remainder of this tutorial. Designing Threaded Programs.
  • In order for a program to take advantage of Pthreads, it must be able to be organized into discrete, independent tasks that can execute concurrently
Posted in Uncategorized | Leave a comment

MESSAGE QUEUES

SATINDER.EMBDEVELOPER

IPC:Message Queues:<sys/msg.h>

The basic idea of a message queue is a simple one.

Two (or more) processes can exchange information via access to a common system message queue. The sending process places via some (OS) message-passing module a message onto a queue which can be read by another process . Each message is given an identification or type so that processes can select the appropriate message. Process must share a common key in order to gain access to the queue in the first place (subject to other permissions — see below)

 

Basic Message Passing IPC messaging lets processes send and receive messages, and queue messages for processing in an arbitrary order. Unlike the file byte-stream data flow of pipes, each IPC message has an explicit length. Messages can be assigned a specific type. Because of this, a server process can direct message traffic between clients on its queue by using the client process PID as the message type. For single-message transactions, multiple server processes can work in parallel on transactions sent to a shared message queue.

Before a process can send or receive a message, the queue must be initialized (through the msgget function see below) Operations to send and receive messages are performed by the msgsnd() and msgrcv() functions, respectively.

When a message is sent, its text is copied to the message queue. The msgsnd() and msgrcv() functions can be performed as either blocking or non-blocking operations. Non-blocking operations allow for asynchronous message transfer — the process is not suspended as a result of sending or receiving a message. In blocking or synchronous message passing the sending process cannot continue until the message has been transferred or has even been acknowledged by a receiver. IPC signal and other mechanisms can be employed to implement such transfer. A blocked message operation remains suspended until one of the following three conditions occurs:

  • The call succeeds.
  • The process receives a signal.
  • The queue is removed.
  • Initialising the Message Queue

The msgget() function initializes a new message queue:

int msgget(key_t key, int msgflg)

It can also return the message queue ID (msqid) of the queue corresponding to the key argument. The value passed as the msgflg argument must be an octal integer with settings for the queue’s permissions and control flags.

The following code illustrates the msgget() function.

#include <sys/ipc.h>;
#include <sys/msg.h>; 

... 

key_t key; /* key to be passed to msgget() */
int msgflg /* msgflg to be passed to msgget() */
int msqid; /* return value from msgget() */ 

...
key = ...
msgflg = ...

if ((msqid = msgget(key, msgflg)) == &ndash;1)
  {
    perror("msgget: msgget failed");
    exit(1);
   } else
    (void) fprintf(stderr, &ldquo;msgget succeeded");
...
Posted in Uncategorized | Leave a comment

IMPLEMENTATION OF THREADS (MORE THAN TWO)

SATINDER.EMBDEVELOPER

RCS file: ./thread,v
Working file: ./thread
head:
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 0
description:
threads created for two childs
=============================================================================

Posted in Uncategorized | Leave a comment

MAKE FILE

SATINDER.EMBDEVELOPER

RCS file: ./makefile,v
Working file: ./makefile
head: 1.1
branch:
locks: strict
satinder: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
make file syntax
—————————-
revision 1.1    locked by: satinder;
date: 2014/03/28 11:28:46;  author: satinder;  state: Exp;
Initial revision
=============================================================================

Posted in Uncategorized | Leave a comment

USE OF SHARE MEMORY IN IPC

BY:-SATINDER.EMBDEVELOPER

Shared Memory:

Shared Memory is an efficeint means of passing data between programs. One program will create a memory portion which other processes (if permitted) can access.

In the Solaris 2.x operating system, the most efficient way to implement shared memory applications is to rely on the mmap() function and on the system’s native virtual memory facility. Solaris 2.x also supports System V shared memory, which is another way to let multiple processes attach a segment of physical memory to their virtual address spaces. When write access is allowed for more than one process, an outside protocol or mechanism such as a semaphore can be used to prevent inconsistencies and collisions.

A process creates a shared memory segment using shmget()|. The original owner of a shared memory segment can assign ownership to another user with shmctl(). It can also revoke this assignment. Other processes with proper permission can perform various control functions on the shared memory segment using shmctl(). Once created, a shared segment can be attached to a process address space using shmat(). It can be detached using shmdt() (see shmop()). The attaching process must have the appropriate permissions for shmat(). Once attached, the process can read or write to the segment, as allowed by the permission requested in the attach operation. A shared segment can be attached multiple times by the same process. A shared memory segment is described by a control structure with a unique ID that points to an area of physical memory. The identifier of the segment is called the shmid. The structure definition for the shared memory segment control structures and prototypews can be found in <sys/shm.h>.

Accessing a Shared Memory Segment

shmget() is used to obtain access to a shared memory segment. It is prottyped by:

int shmget(key_t key, size_t size, int shmflg);

The key argument is a access value associated with the semaphore ID. The size argument is the size in bytes of the requested shared memory. The shmflg argument specifies the initial access permissions and creation control flags.

When the call succeeds, it returns the shared memory segment ID. This call is also used to get the ID of an existing shared segment (from a process requesting sharing of some existing memory portion).

The following code illustrates shmget():

#include <sys/types.h>
#include <sys/ipc.h> 
#include <sys/shm.h> 

... 

key_t key; /* key to be passed to shmget() */ 
int shmflg; /* shmflg to be passed to shmget() */ 
int shmid; /* return value from shmget() */ 
int size; /* size to be passed to shmget() */ 

... 

key = ... 
size = ...
shmflg) = ... 

if ((shmid = shmget (key, size, shmflg)) == -1) {
   perror("shmget: shmget failed"); exit(1); } else {
   (void) fprintf(stderr, "shmget: shmget returned %d\n", shmid);
   exit(0);
  }
...

Controlling a Shared Memory Segment

shmctl() is used to alter the permissions and other characteristics of a shared memory segment. It is prototyped as follows:

int shmctl(int shmid, int cmd, struct shmid_ds *buf);

The process must have an effective shmid of owner, creator or superuser to perform this command. The cmd argument is one of following control commands:

SHM_LOCK
– Lock the specified shared memory segment in memory. The process must have the effective ID of superuser to perform this command.
SHM_UNLOCK
– Unlock the shared memory segment. The process must have the effective ID of superuser to perform this command.
IPC_STAT
– Return the status information contained in the control structure and place it in the buffer pointed to by buf. The process must have read permission on the segment to perform this command.
IPC_SET
– Set the effective user and group identification and access permissions. The process must have an effective ID of owner, creator or superuser to perform this command.
IPC_RMID
– Remove the shared memory segment.

The buf is a sructure of type struct shmid_ds which is defined in <sys/shm.h>

The following code illustrates shmctl():

#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/shm.h>

...

int cmd; /* command code for shmctl() */
int shmid; /* segment ID */
struct shmid_ds shmid_ds; /* shared memory data structure to 
                             hold results */ 
...

shmid = ...
cmd = ...
if ((rtrn = shmctl(shmid, cmd, shmid_ds)) == -1) {
    perror("shmctl: shmctl failed");
    exit(1);
   }
...

Attaching and Detaching a Shared Memory Segment

shmat() and shmdt() are used to attach and detach shared memory segments. They are prototypes as follows:

void *shmat(int shmid, const void *shmaddr, int shmflg);

int shmdt(const void *shmaddr);

shmat() returns a pointer, shmaddr, to the head of the shared segment associated with a valid shmid. shmdt() detaches the shared memory segment located at the address indicated by shmaddr

. The following code illustrates calls to shmat() and shmdt():

#include <sys/types.h> 
#include <sys/ipc.h> 
#include <sys/shm.h> 

static struct state { /* Internal record of attached segments. */ 
          int shmid; /* shmid of attached segment */ 
          char *shmaddr; /* attach point */ 
          int shmflg; /* flags used on attach */
         } ap[MAXnap]; /* State of current attached segments. */
int nap; /* Number of currently attached segments. */

...

char *addr; /* address work variable */
register int i; /* work area */
register struct state *p; /* ptr to current state entry */
...

p = &ap[nap++];
p->shmid = ...
p->shmaddr = ...
p->shmflg = ...

p->shmaddr = shmat(p->shmid, p->shmaddr, p->shmflg);
if(p->shmaddr == (char *)-1) {
     perror("shmop: shmat failed");
     nap--;
    } else
    (void) fprintf(stderr, "shmop: shmat returned %#8.8x\n",
p->shmaddr);

... 
i = shmdt(addr);
if(i == -1) {
    perror("shmop: shmdt failed");
    } else {
  (void) fprintf(stderr, "shmop: shmdt returned %d\n", i);

for (p = ap, i = nap; i--; p++)   
  if (p->shmaddr == addr) *p = ap[--nap];

}
...

Posted in Uncategorized | Leave a comment

RCS LOG FILE OF IMPLEMENTATION MULTIPLE CLIENTS(1000 PROPER WORKING) & SERVER ,PROCESSORS USING “FIFO”(DUAL)

SATINDER.EMBDEVELOPER

My Photo

LOG FILE:————
RCS file: ./clints.c,v
Working file: ./clint1.c
head: 1.1
branch:
locks: strict
satinder: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
SUCESSFULLY DONE FIFO IN IPC WITH MULTIPLE CLIENTS AND PROCESSORS (1000).
—————————-
revision 1.1 locked by: satinder;
date: 2014/03/28 10:44:22; author: satinder; state: Exp;
Initial revision
=============================================================================
RCS file: ./clints.c,v
Working file: ./clint1.c
head: 1.2
branch:
locks: strict
satinder: 1.2
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
SUCESSFULLY DONE FIFO IN IPC WITH MULTIPLE CLIENTS AND PROCESSORS (1000).
—————————-
revision 1.2    locked by: satinder;
date: 2014/03/28 10:44:22;  author: satinder;  state: Exp;
Initial revision
=============================================================================

RCS file: ./clints.c,v
Working file: ./clint1.c
head: 1.3
branch:
locks: strict
satinder: 1.3
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
SUCESSFULLY DONE FIFO IN IPC WITH MULTIPLE CLIENTS AND PROCESSORS (1000).
—————————-
revision 1.3   locked by: satinder;
date: 2014/03/28 10:44:22;  author: satinder;  state: Exp;
Initial revision
=============================================================================

RCS file: ./server.c,v
Working file: ./server.c
head: 1.1
branch:
locks: strict
satinder: 1.1
access list:
symbolic names:
keyword substitution: kv
total revisions: 1;    selected revisions: 1
description:
COMPLETE INTER PROCESS COMMUNICATION BETWEEN CLIENT &amp; SERVER WITH PROPER TIMING .
—————————-
revision 1.1    locked by: satinder;
date: 2014/03/23 11:29:44;  author: satinder;  state: Exp;
Initial revision
=============================================================================

Posted in Uncategorized | Leave a comment

program of reversing link list using three pointer.

rlog: RCS/vim,v: No such file or directory

RCS file: llrev.c,v
Working file: llrev.c
head: 1.2
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 2; selected revisions: 2
description:
this is the program of structure in which i have entered data and link each data to node.
—————————-
revision 1.2
date: 2014/03/28 10:31:36; author: root; state: Exp; lines: +74 -22
this is the program ofreversing the link list using three pointer.
—————————-
revision 1.1
date: 2014/03/28 08:07:54; author: root; state: Exp;
Initial revision
============================================

Posted in Uncategorized | Leave a comment