Its Nag's blog. check it out....

TALKING TO HARDWARE in C language.

2009-09-27T05:06:00.000-07:00

inportb
Syntax
#include
unsigned char inportb(unsigned short _port);
Description
Read a single 8-bit I/O port.
This function is provided as an inline assembler macro, and will be optimized down to a single opcode when you optimize your program.
Return Value
The value returned through the port.
Portability
ANSI/ISO C No
POSIX No
*****************************************
Inportl
Syntax
#include
unsigned long inportl(unsigned short _port);
Description
This function reads a single 32-bit I/O port.
This function is provided as an inline assembler macro, and will be optimized down to a single opcode when you optimize your program.
Return Value
The value returned from the port.
Portability
ANSI/ISO C No
POSIX No
************************************************************
inportsb
Syntax
#include
void inportsb(unsigned short _port, unsigned char *_buf, unsigned _len);
Description
Reads the 8-bit _port _len times, and stores the bytes in buf.
Portability
ANSI/ISO C No
POSIX No
*************************************************************
inportsl
Syntax
#include
void inportsl(unsigned short _port, unsigned long *_buf, unsigned _len);
Description
Reads the 32-bit _port _len times, and stores the bytes in buf.
Portability
ANSI/ISO C No
POSIX No
*************************************************************
inportsw
Syntax
#include
void inportsw(unsigned short _port,
unsigned short *_buf, unsigned _len);
Description

Reads the 16-bit _port _len times, and stores the bytes in buf.
Portability
ANSI/ISO C No
POSIX No
**********************************************
inportw
Syntax
#include
unsigned short inportw(unsigned short _port);
Description
Read a single 16-bit I/O port.
This function is provided as an inline assembler macro, and will be optimized down to a single opcode when you optimize your program.
Return Value
The value returned through the port.
Portability
ANSI/ISO C No
POSIX No
**************************************************
inpw
Syntax

#include
unsigned short inpw(unsigned short _port);
Description
Calls inportw. Provided only for compatibility.
Portability
ANSI/ISO C No
POSIX No

*******************************************
Similarily with outport() also
All the above function are same for sendting data .. except change the in prefix to out

Socket Program in C

2009-09-27T04:57:00.000-07:00

hey guys ! socket programing in C language..

you can chat with your friend .using this program,, try it ..

. TCP
* TCP server : simple TCP server that prints received messages.
source : tcpServer.c
usage : ./tcpServer
* TCP client : simple TCP client that sends data to server.
source : tcpClient.c
usage : ./tcpClient server data1 ... dataN

/*********************** tcpserver.c ***********************/
#include
#include
#include
#include
#include
#include
#include /* close */

#define SUCCESS 0
#define ERROR 1
#define END_LINE 0x0
#define SERVER_PORT 1500
#define MAX_MSG 100
/* function readline */
int read_line();
int main (int argc, char *argv[]) {
int sd, newSd, cliLen;
struct sockaddr_in cliAddr, servAddr;
char line[MAX_MSG];

/* create socket */
sd = socket(AF_INET, SOCK_STREAM, 0);
if(sd<0) {
perror("cannot open socket ");
return ERROR;
}
/* bind server port */
servAddr.sin_family = AF_INET;
servAddr.sin_addr.s_addr = htonl(INADDR_ANY);
servAddr.sin_port = htons(SERVER_PORT);
if(bind(sd, (struct sockaddr *) &servAddr, sizeof(servAddr))<0) {
perror("cannot bind port ");
return ERROR;
}
listen(sd,5);
while(1) {
printf("%s: waiting for data on port TCP %u\n",argv[0],SERVER_PORT);
cliLen = sizeof(cliAddr);
newSd = accept(sd, (struct sockaddr *) &cliAddr, &cliLen);
if(newSd<0) {
perror("cannot accept connection ");
return ERROR;
}
/* init line */
memset(line,0x0,MAX_MSG);
/* receive segments */
while(read_line(newSd,line)!=ERROR) {
printf("%s: received from %s:TCP%d : %s\n", argv[0],
inet_ntoa(cliAddr.sin_addr),
ntohs(cliAddr.sin_port), line);
/* init line */
memset(line,0x0,MAX_MSG);
} /* while(read_line) */
} /* while (1) */
}

/* WARNING WARNING WARNING WARNING WARNING WARNING WARNING */
/* this function is experimental.. I don't know yet if it works */
/* correctly or not. Use Steven's readline() function to have */
/* something robust. */
/* WARNING WARNING WARNING WARNING WARNING WARNING WARNING */
/* rcv_line is my function readline(). Data is read from the socket
when */
/* needed, but not byte after bytes. All the received data is read.
*/
/* This means only one call to recv(), instead of one call for
*/
/* each received byte.
*/
/* You can set END_CHAR to whatever means endofline for you. (0x0A is
\n)*/
/* read_lin returns the number of bytes returned in line_to_return
*/
int read_line(int newSd, char *line_to_return) {
static int rcv_ptr=0;
static char rcv_msg[MAX_MSG];
static int n;
int offset;
offset=0;
while(1) {
if(rcv_ptr==0) {
/* read data from socket */
memset(rcv_msg,0x0,MAX_MSG); /* init buffer */
n = recv(newSd, rcv_msg, MAX_MSG, 0); /* wait for data */
if (n<0) {
perror(" cannot receive data ");
return ERROR;
} else if (n==0) {
printf(" connection closed by client\n");
close(newSd);
return ERROR;
}
}
/* if new data read on socket */
/* OR */
/* if another line is still in buffer */
/* copy line into 'line_to_return' */
while(*(rcv_msg+rcv_ptr)!=END_LINE && rcv_ptrmemcpy(line_to_return+offset,rcv_msg+rcv_ptr,1);
offset++;
rcv_ptr++;
}
/* end of line + end of buffer => return line */
if(rcv_ptr==n-1) {
/* set last byte to END_LINE */
*(line_to_return+offset)=END_LINE;
rcv_ptr=0;
return ++offset;
}
/* end of line but still some data in buffer => return line */
if(rcv_ptr /* set last byte to END_LINE */
*(line_to_return+offset)=END_LINE;
rcv_ptr++;
return ++offset;
}
/* end of buffer but line is not ended => */
/* wait for more data to arrive on socket */
if(rcv_ptr == n) {
rcv_ptr = 0;
}
} /* while */
}

/*********************** tcpclient.c ***********************/

/* tcpClient.c */
#include
#include
#include
#include
#include
#include
#include /* close */
#define SERVER_PORT 1500
#define MAX_MSG 100
int main (int argc, char *argv[]) {
int sd, rc, i;
struct sockaddr_in localAddr, servAddr;
struct hostent *h;
if(argc < 3) {
printf("usage: %s ... \n",argv[0]);
exit(1);
}
h = gethostbyname(argv[1]);
if(h==NULL) {
printf("%s: unknown host '%s'\n",argv[0],argv[1]);
exit(1);
}
servAddr.sin_family = h->h_addrtype;
memcpy((char *) &servAddr.sin_addr.s_addr, h->h_addr_list[0],
h->h_length);
servAddr.sin_port = htons(SERVER_PORT);
/* create socket */
sd = socket(AF_INET, SOCK_STREAM, 0);
if(sd<0) {
perror("cannot open socket ");
exit(1);
}
/* bind any port number */
localAddr.sin_family = AF_INET;
localAddr.sin_addr.s_addr = htonl(INADDR_ANY);
localAddr.sin_port = htons(0);
rc = bind(sd, (struct sockaddr *) &localAddr, sizeof(localAddr));
if(rc<0) {
printf("%s: cannot bind port TCP %u\n",argv[0],SERVER_PORT);
perror("error ");
exit(1);
}
/* connect to server */
rc = connect(sd, (struct sockaddr *) &servAddr, sizeof(servAddr));
if(rc<0) {
perror("cannot connect ");
exit(1);
}
for(i=2;i greater than argc;i++) {
rc = send(sd, argv[i], strlen(argv[i]) + 1, 0);
if(rc<0) {
perror("cannot send data ");
close(sd);
exit(1);
}
printf("%s: data%u sent (%s)\n",argv[0],i-1,argv[i]);
}
return

}

Some STUFF which helps U (SORTING TECHNIQUES)

2009-04-03T09:35:00.000-07:00

insertion sort:-

One of the simplest sorting algorithms is the insertion sort. The code for the algorithm is as follows:

for(i = 1; i <>
Inserted = false; //boolean variable
j = i;
while((j >= 1) && (Inserted == false){
if(List[j] <>
swap(List[j], List[j-1]);
else
Inserted=true;
j--;
}
}

This algorithm works by first considering the first element of the list (element 0) to be correctly placed. It proceeds to the next element (element 1) and compares its value with. If the magnitude is smaller, it swaps it with element 0. Now, elements 0 and 1 are sorted, but only with respect to each other. Element 2 is now considered, and is moved to its correct position with respect to elements 0 and 1, i.e., it may stay where it currently is, or it may be placed between what are now elements 0 and 1, or it may be placed before element 0. To do this, elements 2 and 1 may be swapped, resulting in the placement of element 2 between what is currently element 0 and element 1, and then another swap between what are now elements 0 and 1 may be done to place the element before what is now element 0. This continues over and over again, considering the elements from element 3 through the last element of the list. Each element is placed in its proper position in the part of the list already consider to be sorted. Each element under consideration is swapped with its immediately preceeding neighbour as it moves towards the front of the list. The moment the swapping stops, the element's immediately preceding neighbor has lesser magnitude, and so the current element may be considered to be properly placed.

Complexity:

In this method there are N-1 insert operations. The j-th insert operation inserts a new element into a sorted array of j elements and hence takes at most j comparisions. Thus the total number of comparisions are:

1 + 2 + 3 + ... + (N-1) = N*(N-1)/2 = O(N^2)

INSERTION SORT II

iNSERTION SORT (A)
for j <-- 2 to length[A]
do key<--A[j]
//Insert A[j] into the sorted sequence A[1 . . . .j-1]
i <-- j - 1 while i > 0 and A[i] > key
do A[i + 1] <-- A[i]
i <-- i -1 A[i + 1] <-- key

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

COUNTING SORT

Counting sort is a linear time sorting algorithm used to sort items when they belong to a fixed and finite set. Integers which lie in a fixed interval, say k1 to k2, are examples of such items.

The algorithm proceeds by defining an ordering relation between the items from which the set to be sorted is derived (for a set of integers, this relation is trivial).Let the set to be sorted be called A. Then, an auxiliary array with size equal to the number of items in the superset is defined, say B. For each element in A, say e, the algorithm stores the number of items in A smaller than or equal to e in B(e). If the sorted set is to be stored in an array C, then for each e in A, taken in reverse order, C[B[e]] = e. After each such step, the value of B(e) is decremented.

The algorithm makes two passes over A and one pass over B. If size of the range k is smaller than size of input n, then time complexity=O(n). Also, note that it is a stable algorithm, meaning that ties are resolved by reporting those elements first which occur first.

This visual demonstration takes 8 randomly generated single digit numbers as input and sorts them. The range of the inputs are from 0 to 9.

COUNTING SORT(A,B,k)

1 for i = 1 to k

2 do c[i] = 0
3 for j = 1 to length[A]

4 do C[A[j]] = C[A[j]] + 1
5 >C[i] now contains the number of elements equal to i

6 for i = 2 to k

7 do C[i] = C[i] + C[i-1]

8 >C[i] now contains the number of elements less than or equal to i

9 for j = length[A] downto 1

10 do B[C[A[j]]] = A[j]

11 C[A[j]] = C[A[J]] - 1
//////////////////////////////////////////////////////////////////////////////////////////////////
HEAP SORT
The heapsort algorithm uses the data structure called the heap. A heap is defined as a complete binary tree in which each node has a value greater than both its children (if any). Each node in the heap corresponds to an element of the array, with the root node corresponding to the element with index 0 in the array. Considering a node corresponding to index i, then its left child has index (2i + 1) and its right child has index (2i + 2). If any or both of these elements do not exist in the array, then the corresponding child node does not exist either. Note that in a heap the largest element is located at the root node. The code for the algorithm is:

Heapify(A, i){
l <- left(i)
r <- right(i)
if l <= heapsize[A] and A[l] > A[i]
then largest <- l
else largest <- i
if r <= heapsize[A] and A[r] > A[largest]
then largest <- r
if largest != i
then swap A[i] <-> A[largest]
Heapify(A, largest)
}

Buildheap(A){
heapsize[A] <- length[A]
for i <- |length[A]/2| downto 1
do Heapify(A, i)
}

Heapsort(A){
Buildheap(A)
for i <- length[A] downto 2
do swap A[1] <-> A[i]
heapsize[A] <- heapsize[A] - 1
Heapify(A, 1)
}

Heap Sort operates by first converting the initial array into a heap. The HeapSort algorithm uses a process called Heapify to accomplish its job. The Heapify algorithm, as shown above, receives a binary tree as input and converts it to a heap. The root is then compared with its two immediate children, and the larger child is swapped with it. This may result in one of the left or right subtrees losing their heap property. Consequently, the Heapify algorithm is recursively applied to the appropriate subtree rooted at the the node whose value was just swapped with the root and the process continues until either a leaf node is reached, or it is determined that the heap property is satisfied in the subtree.

The entire HeapSort method consists of two major steps:

STEP 1: Construct the initial heap using adjust (N/2) times on all non-leaf nodes.
STEP 2: Sort by swapping and adjusting the heap (N-1) times.

In step 2, since the largest element of the heap is always at the root, after the initial heap is constructed, the root value is swapped with the lowest, rightmost element. This node corresponds to the last element of the array and so after the swapping the righmost element of the array has the largest value, which is what we want it to have. Consequently, the rightmost element is correctly place, and so the corresponding node becomes a light gray in the tree display depicting the heap. Also, the elements (nodes) chosen for swapping at this point of the algorithm are shown as yellow nodes.

Thereafter, since the value of the lowest, rightmost node has moved up to the root, the heap property of the rest of the heap (minus the gray nodes) has been disturbed. Consequently, now the Heapify process is applied to the rest of the heap (treating the light gray nodes as though they were no longer a part of the heap). Once the rest of the heap is again converted to a proper heap, the swapping process as described in the previous paragraph, followed by the Heapify process is applied again. This continues until the root node of the heap turns light gray - i.e., the root has its correct value. Then, the array is sorted.

At each step of the Heapify algorithm, a node is compared to its children and one of them is chosen as the next root. One level of the tree is dropped at each step of this process. Since the heap is a complete binary tree, there are atmost log(N) levels. Thus, the worst case time complexity of Heapify is O(log(N)). In the Heapsort algorithm, Heapify is used (N/2) times to construct the initial heap and (N-1) times to sort. Thus the Heapsort algorithm has a worst case time complexity of O(N*log(N)).

******************************************************************************

POSTMAN SORT

Postman Sort is probably the newest linear order sorting algorithm for fixed domain sets in use today. It's developers claim that it is also the fastest such algorithm.

The algorithm works by sorting the numbers from their most significant digit to their least significant digit. Significant gain in speed is achieved by sorting the numbers on more than one digit at a time (the actual number is decided based on the size of the computer's memory). The process is also considerably speeded up by using some knowledge of the range in which the numbers lie, for example the fact that digits of octal numbers lie in the range 0 to 7.

For this visual demonstration we have sorted randomly input 9 digit binary numbers, using 3 digits at a time (The use of binary numbers enhances the clarity of the visual representation considerably).
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

RADIX SORT

Radix sort is one of the linear sorting algorithms for integers. It functions by sorting the input numbers on each digit, for each of the digits in the numbers. However, the process adopted by this sort method is somewhat counterintuitive, in the sense that the numbers are sorted on the least-significant digit first, followed by the second-least significant digit and so on till the most significant digit.

To appreciate Radix Sort, consider the following analogy: Suppose that we wish to sort a deck of 52 playing cards (the different suits can be given suitable values, for example 1 for Diamonds, 2 for Clubs, 3 for Hearts and 4 for Spades). The 'natural' thing to do would be to first sort the cards according to suits, then sort each of the four seperate piles, and finally combine the four in order. This approach, however, has an inherent disadvantage. When each of the piles is being sorted, the other piles have to be kept aside and kept track of. If, instead, we follow the 'counterintuitive' aproach of first sorting the cards by value, this problem is eliminated. After the first step, the four seperate piles are combined in order and then sorted by suit. If a stable sorting algorithm (i.e. one which resolves a tie by keeping the number obtained first in the input as the first in the output) it can be easily seen that correct final results are obtained.

As has been mentioned, the sorting of numbers proceeds by sorting the least significant to most significant digit. For sorting each of these digit groups, a stable sorting algorithm is needed. Also, the elements in this group to be sorted are in the fixed range of 0 to 9. Both of these characteristics point towards the use of Counting Sort as the sorting algorithm of choice for sorting on each digit (If you haven't read the description on Counting Sort already, please do so now).

The time complexity of the algorithm is as follows: Suppose that the n input numbers have maximum k digits. Then the Counting Sort procedure is called a total of k times. Counting Sort is a linear, or O(n) algorithm. So the entire Radix Sort procedure takes O(kn) time. If the numbers are of finite size, the algorithm runs in O(n) asymptotic time.
A graphical representation of the entire procedure has been provided in the attached applet. This program takes 8 randomly generated 3 digit integers as input and sorts them using Radix Sort.

RADIX-SORT(A,d)

1 for i - 1 to d

2 do use a stable sort to sort Array A on digit i

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The mergesort algorithm closely follows the divide-and-conquer paradigm. Generally, Merge Sort is considered to be one of the best internal sorting methods. If the data is too large to be accommodated all at once in the memory then one has to use external sorting methods. In external sorting methods small blocks of data are loaded into the memory, sorted using an internal sorting method and written out to a tape or disk. Sorted parts are then merged using variations of the merging algorithm discussed below:

Mergesort(A,p,r){
if p <>
then q <- |(p+ r)/2|
Mergesort(A,p,q)
Mergesort(A,q+1,r)
Merge(A,p,q,r)
}

To sort the entire sequence A, Mergesort(A,1,length[A]) is called where length[A]=N.

Mergesort works by splitting the list into two halves and then sorting each half recursively. Mergesort may be considered to be a tree based algorithm and over here it is executed in a depth first manner. For the above list the algorithm starts by handling the merging of elements as follows (the trend in which the sublists are being considered):

1. First, elements 1 and 2 are handled.
2. Then, elements from 0 through 2 are handled (note the black items indicating the border elements).
3. Then, elements 3 and 4 are handled. After this, elements 5 and 6.
4. Then, elements 3 through 6 are handled.

Subsequently, elements 0 through 6 are handled and so on until elements 0 to 14 are handled.

The Merge algorithm takes two sorted lists and merges them to give a sorted list. It assumes the existence of a temporary merge space whose current contents are shown on the upper canvas of the above applet. Mereg takes the the smaller of the first elements of the two lists and places it into the merge space. When either input list is exhausted, the remainder of the other list is copied to the merge space. The sorted sublist is then copied back from the merge space into the appropriate indices.

Merge Sort algorithm uses the process of merging two sorted lists recursively to accomplish the sorting of an unsorted list. Firstly, two sorted lists of length M and N respectively can be merged in O(M+N) time. If the lists have the same size N then the time will be O(2*N) or O(N).
First, each individual element of the list is considered as a 1-element sorted list. The merge algorithm is then used N/2 times to merge pairs of elements into sorted lists of length 2. This will produce N/2 sorted lists each of length 2. It takes N/2 comparisons to accomplish this. Pairs of 2-element lists are then merged to produce N/4 sorted lists each of length 4. In this case there are N/4 merge operations each taking at most 4 comparisons. This process continues until we have two sorted lists of size N/2 and we merge them in O(N) time. There are log(N) levels of merging. Hence, Merge Sort has a worst-case complexity of O(N*log(N)).

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

HEAPSORT ii

The running time of heapsort is O(N*lgN) i.e. it achieves the lower bound for computational based sorting.

HEAP
The heap data structure is an array object which can be easily visualized as a complete binary tree.There is a one to one correspondence between elements of the array and nodes of the tree.The tree is completely filled on all levels except possibly the lowest,which is filled from the left upto a point.All nodes of heap also satisfy the relation that the key value at each node is at least as large as the value at its children.

Step I: The user inputs the size of the heap(within a specified limit).The program generates a corresponding binary tree with nodes having randomly generated key Values.

Step II: Build Heap Operation:Let n be the number of nodes in the tree and i be the key of a tree.For this,the program uses operation Heapify.when Heapify is called both the left and right subtree of the i are Heaps.The function of Heapify is to let i settle down to a position(by swapping itself with the larger of its children,whenever the heap property is not satisfied)till the heap property is satisfied in the tree which was rooted at (i).This operation calls

Step III: Remove maximum element:The program removes the largest element of the heap(the root) by swapping it with the last element.

Step IV: The program executes Heapify(new root) so that the resulting tree satisfies the heap property.
Step V: Goto step III till heap is empty

Quicksort is based on the divide and conquer approach and inspite of its slow worst case running time, it is often the best practical choice for sorting because it is remarkably efficient on the average. The following code describes the algorithm:

QuickSort(A, p, r){
if p <>
then q <- Partition(A, p, r)
QuickSort(A, p, q)
QuickSort(A, q+1, r)
}

To sort an entire array A, the initial call is QuickSort(A, 1, length[A]).

Partition(A, p, r){
x <- A[p]
i <- p - 1
j <- r + 1
while TRUE
do repeat j <- j - 1
until A[j] <= x
repeat i <- i + 1
until A[i] >= x
if i <>
then exchange A[i] <-> A[j]
else return j
}

The algorithm starts by first performing a scan of the entire list, as indicated by the two black items at the two ends of the list. It attempts then to partition the list. The manner in which this partitioning is done is: First, the pivot element is considered to be the first element of the (sub)list being scanned, i.e., element 0. The high-pointer is shown in green and the low-pointer in blue. Scanning of the (sub)list consists of decrementing the high-pointer and incrementing the low-pointer until A[low-pointer]>= A[pivot] >= A[high-pointer]. As the scan of the (sub)list proceeds, the magnitudes of the list elements are compared with the magnitude of the pivot. First the high-pointer is decremented till it meets an element that is less than or equal to the pivot. Then the low-pointer is incremented till it meets an element greater than equal to the pivot. If the low-pointer is less than the high-pointer, then the elements pointed to by these are swapped else the element pointed by the high-pointer becomes the pivot. Conceptually, the partitioning procedure performs a simple function: it puts elemnts smaller than the pivot into the bottom region of the array and elements larger than the pivot into the top region. Now, the same partitioning approach can be recursively applied to the smaller sublist and also to the larger sublist obtained as a result of the partitioning. Repeated applications of this approach to all sublists generated results in a sorted list.

Quicksort works by partitioning the list into two parts. The first partitioning of the N elements in list positions 0 to N-1, compares and swaps them to produce a pivotal index j such that the elements in positions 0 to j-1 are less than or equal to the pivot which is now in the jth position and those elements in positions j+1 to N-1 are greater. This is accomplished in O(N) time.
The first partition produces two sublists such that sorting of each of them results in the sorting of the original list. The partitioning technique is applied recursively to each half until the halves reduce to single-element or empty lists.
Assuming that the list breaks into two halves of equal size, then we have two lists of size N/2 to sort. Each of these has to be partitioned which takes (N/2) + (N/2) = N comparisions. Continuing the same assumption, there will be atmost log(N) splits. This results in the best case time estimate of O(N*log(N)) for quicksort.
In the worst case, the partitioning routine produces one region with (N-1) elements and one with only one element (this happens when the list to be sorted is already sorted). This gives a worst case time of O(N^2). However, quicksort takes O(N*log(N)) in the average case.2

MERGE SORT

The mergesort algorithm is based on the classical divide-and-conquer paradigm. It operates as follows:

DIVIDE: Partition the n-element sequence to be sorted into two subsequences of n/2 elements each.

CONQUER: Sort the two subsequences recursively using the mergesort.

COMBINE: Merge the two sorted sorted subsequences of size n/2 each to produce the sorted sequence consisting of n elements.

Note that recursion "bottoms out" when the sequence to be sorted is of unit length. Since every sequence of length 1 is in sorted order, no further recursive call is necessary. The key operation of the mergesort algorithm is the merging of the two sorted sequencesin the "combine step". To perform the merging, we use an auxilliary procedure Merge(A,p,q,r), where A is an array and p,q and r are indices numbering elements of the array such that dure assumes that the subarrays A[p..q] and A[q+1...r] are in sorted order.It merges them to form a single sorted subarray that replaces the current subarray A[p..r]. Thus finally,we obtain the sorted array A[1..n], which is the solution.

MERGE SORT (A,p,r)
1 if p <>then q<-- [ (p + r) / 2 ] 3 MERGE SORT(A,p,q)
4 MERGER SORT(A,q + 1,r)
5 MERGE(A,p,q,r)

QUICK SORT

Quick sort,is based on the divide-and-conquer paradigm.It is a sorting algorithm with worst case running time O(n^2) on an input array of n numbers.In spite of this slow worst case running time,quicksort is often the best practical choice for sorting because it is remarkably efficient on the average : its expected running time is O(nlgn) and the constants hidden in the O-notation are quite small.Here is the three-step divide-and-conquer process for sorting a typical array A[p . . . r]

DIVIDE:The array >A is partitioned (rearranged) into two nonempty subarrays A[p . . q] and A[q+1 . . r].The index q is computed as a part of this partitioning procedure.

CONQUER:The two subarrays A[p . . q] and A[q+1 . . r] are sorted by recursive calls to quicksort.

COMBINE:Since the subarrays are sorted in place, no work is needed to combine them : the entire array A is now sorted.

QUICK SORT (A,p,r)
1 if p <>then q<-- PARTITION(A,p,r)
3 QUICK SORT(A,p,q)
4 QUICK SORT(A,q + 1,r)

POST Power On Self Test .. Know your computer...

2009-03-19T11:19:00.000-07:00

What happens when your computer starts up and when it shuts down
Starting Up
What happens when a computer starts? - POST - Power On Self Test
Although there are differences in how each computer actually starts, they all share these basic steps. This example is particularly directed towards Dos and Windows (except where noted).
• The computer performs a test on itself to make sure all components are available and ready. One important part of the first steps is that the registers (the place where data and instructors go in the CPU to be processed) are cleared of any old code. This is the start of the Power-On Self Test or POST test.
• The CPU then gets a memory address from the ROM which where to find the ROM BIOS in order to continue the check.
• The CPU now sends signals on its system bus, the main circuit on the mother board to which all components are attached.
• The clock is checked by the CPU. All computer functions are regulated by this clock, which sends an impulse at a regular interval. It is very much similar to the beating of a bass drum to mark time in music.
• POST tests the memory chips on the video adapter and loads information from the video adapter’s own BIOS into the system BIOS. Sometimes the BIOS codes from slower CMOS are also loaded into RAM. Newer PCs have additional equipment which also have their own BIOS on their own cards. These items, called plug and play also get loaded into the system BIOS.
• The CPU now checks to see if a keyboard is attached, if it is working correctly and if any keys are pressed. Many operating systems permit the user to interrupt the POST test to change the computer’s initial or default behaviors (or environmental variables).
• POST now checks the paths on the bus to the floppy and harddrives (and other devices) to see what storage and peripheral devices are available.
• Once all the components contribute information to the system BIOS, and all other checks have been performed, if the test indicates a problem, such as a corrupted FAT table, the test will inform you and usually offer a change to fix the problem via a setup screen. If there are no problems, the operating system will display some form of greeting: on a Windows machine, you see a large Microsoft logo. On a Macintosh, you’ll read "Welcome to Macintosh." Command-line systems, such as Unix, may show nothing but a prompt.

To start the computer in safe mode
You should print these instructions before continuing. They will not be available after you shut your computer down in step 2.
1. Click Start, click Shut Down, and then, in the drop-down list, click Shut down.
2. In the Shut Down Windows dialog box, click Restart, and then click OK.
3. When you see the message Please select the operating system to start, press F8.
4. Use the arrow keys to highlight the appropriate safe mode option, and then press ENTER.
5. If you have a dual-boot or multiple-boot system, choose the installation that you need to access using the arrow keys, and then press ENTER.
Notes
In safe mode, you have access to only basic files and drivers (mouse, monitor, keyboard, mass storage, base video, default system services, and no network connections). You can choose the Safe Mode with Networking option, which loads all of the above files and drivers and the essential services and drivers to start networking, or you can choose the Safe Mode with Command Prompt option, which is exactly the same as safe mode except that a command prompt is started instead of the graphical user interface. You can also choose Last Known Good Configuration, which starts your computer using the registry information that was saved at the last shutdown.
Safe mode helps you diagnose problems. If a symptom does not reappear when you start in safe mode, you can eliminate the default settings and minimum device drivers as possible causes. If a newly added device or a changed driver is causing problems, you can use safe mode to remove the device or reverse the change.
There are circumstances where safe mode will not be able to help you, such as when Windows system files that are required to start the system are corrupted or damaged. In this case, the Recovery Console may help you.
NUM LOCK must be off before the arrow keys on the numeric keypad will function.

Shutting Down
What happens when you shut down
Shut Down allows you to gracefully shut down Windows by first saving any open files or reminding you to do so, and then deleting any temporary files that have been in use and are no longer needed. The Shut Down option gives you the option to restart your computer, the equivalent of rebooting, either back into Windows or to DOS. You can protect yourself from losing unsaved information by always using Shut Down when leaving Windows and turning off your computer.
To turn off the computer
Click Start, click Shut Down, and then, in the drop-down list, click Shut down.
This action shuts down Windows so that you can safely turn off the computer power. Many computers turn the power off automatically.
To restart your computer
Click Start, and then click Shut Down.
In the What do you want the computer to do drop-down list, click Restart.
As a last resort
Hit Ctrl-Alt-Delete. The Task Manager should come up. Try closing down any open/stalled programs by hitting End Task (and End Task again if the window comes up), and then Shut Down again. If that doesn't work, hit Ctrl-Alt-Delete several times until the computer reboots. As a final resort, hold the power button on the computer in until the computer shuts off.

Know Your Computer..

Serial Communication Porgramming In C..

2009-03-19T11:03:00.000-07:00

RS232 is the most known serial port used in transmitting the data in communication and interface. Even though serial port is harder to program than the parallel port, this is the most effective method in which the data transmission requires less wires that yields to the less cost. The RS232 is the communication line which enables the data transmission by only using three wire links. The three links provides ‘transmit’, ‘receive’ and common ground...

To download the code ..........http://electrosofts.com/serial/

You find a link for sample code.. download it

Computer Register..Play with it....

2009-03-19T10:52:00.000-07:00

In computer architecture, a processor register is a small amount of storage available on the CPU whose contents can be accessed more quickly than storage available elsewhere. Most, but not all, modern computer architectures operate on the principle of moving data from main memory into registers, operating on them, then moving the result back into main memory—a so-called load-store architecture. A common property of computer programs is locality of reference: the same values are often accessed repeatedly; and holding these frequently used values in registers improves program execution performance.

Processor registers are at the top of the memory hierarchy, and provide the fastest way for a CPU to access data. The term is often used to refer only to the group of registers that are directly encoded as part of an instruction, as defined by the instruction set. More properly, these are called the "architectural registers". For instance, the x86 instruction set defines a set of eight 32-bit registers, but a CPU that implements the x86 instruction set will often contain many more registers than just these eight.

Allocating frequently used variables to registers can be critical to a program's performance. This action, namely register allocation is performed by a compiler in the code generation phase.

Categories of registers

Registers are normally measured by the number of bits they can hold, for example, an "8-bit register" or a "32-bit register". Registers are now usually implemented as a register file, but they have also been implemented using individual flip-flops, high speed core memory, thin film memory, and other ways in various machines.

A processor often contains several kinds of registers, that can be classified according to their content or instructions that operate on them:

* User-accessible Registers - The most common division of user-accessible registers is into data registers and address registers.
* Data registers are used to hold numeric values such as integer and floating-point values. In some older and low end CPUs, a special data register, known as the accumulator, is used implicitly for many operations.
* Address registers hold addresses and are used by instructions that indirectly access memory.
o Some processors contain registers that may only be used to hold an address or only to hold numeric values (in some cases used as an index register whose value is added as an offset from some address); others allow registers hold either kind of quantity. A wide variety of possible addressing modes, used to specify the effective address of an operand, exist.

To Know more .....follow the link Processor and Regiters

Web programming at your finger tips ......

2009-03-12T08:08:00.000-07:00

Its a great site for learning web programming........
visit the site .....Become Web Programmer within no time...

Whats Red Tacton.........

2009-03-02T10:18:00.000-08:00

RedTacton is a new Human Area Networking technology that uses the surface of the human body as a safe, high speed network transmission path..................................

to know more...........click
http://www.redtacton.com/en/info/index.html

its_nags_blog@youfindeverything.com

CAPTCHA...

2009-03-02T10:14:00.000-08:00

Telling Humans and Computers Apart Automatically

A CAPTCHA is a program that can generate and grade tests that humans can pass but current computer programs cannot. For example, humans can read distorted text ........................

Use this link for more details...........
http://recaptcha.net/captcha.html

2009-03-01T03:18:00.000-08:00

The fundamentals of RTOS

To most people, embedded systems are not recognizable as computers. Instead, they are hidden inside everyday objects that surround us and help us in our lives. Embedded systems typically do not interface with the outside world through familiar personal computer interface devices such as a mouse, keyboard and graphic user interface. Instead, they interface with the outside world through unusual interfaces such as sensors, actuators and specialized communication links.

Real-time and embedded systems operate in constrained environments in which computer memory and processing power are limited. They often need to provide their services within strict time deadlines to their users and to the surrounding world. It is these memory, speed and timing constraints that dictate the use of real-time operating systems in embedded software.

Basic kernel services

In the discussion below, we will focus on the "kernel" – the part of an operating system that provides the most basic services to application software running on a processor.

The "kernel" of a real-time operating system ("RTOS") provides an "abstraction layer" that hides from application software the hardware details of the processor (or set of processors) upon which the application software will run. This is shown in Figure1.

Figure 1: An RTOS Kernel provides an Abstraction Layer between Application Software and Embedded Hardware

In providing this "abstraction layer" the RTOS kernel supplies five main categories of basic services to application software, as seen in Figure 2.

Figure 2: Basic Services Provided by a Real-Time Operating System Kernel

The most basic category of kernel services, at the very center of Figure 2, is Task Management. This set of services allows application software developers to design their software as a number of separate "chunks" of software -- each handling a distinct topic, a distinct goal, and perhaps its own real-time deadline. Each separate "chunk" of software is called a "task." Services in this category include the ability to launch tasks and assign priorities to them. The main RTOS service in this category is the scheduling of tasks as the embedded system is in operation. The Task Scheduler controls the execution of application software tasks, and can make them run in a very timely and responsive fashion. [Later, we will see the details of how this is done.]

The second category of kernel services, shown at the top of Figure 2, is Intertask Communication and Synchronization. These services make it possible for tasks to pass information from one to another, without danger of that information ever being damaged. They also make it possible for tasks to coordinate, so that they can productively cooperate with one another. Without the help of these RTOS services, tasks might well communicate corrupted information or otherwise interfere with each other.

Since many embedded systems have stringent timing requirements, most RTOS kernels also provide some basic Timer services, such as task delays and time-outs. These are shown on the right side of Figure 2.

Many (but not all) RTOS kernels provide Dynamic Memory Allocation services. This category of services allows tasks to "borrow" chunks of RAM memory for temporary use in application software. Often these chunks of memory are then passed from task to task, as a means of quickly communicating large amounts of data between tasks. Some very small RTOS kernels that are intended for tightly memory-limited environments, do not offer Dynamic Memory Allocation services.

Many (but not all) RTOS kernels also provide a "Device I/O Supervisor" category of services. These services, if available, provide a uniform framework for organizing and accessing the many hardware device drivers that are typical of an embedded system. [For more information on this, please visit: the device drivers page at the Kalinsky Associates Website]

In addition to kernel services, many RTOSs offer a number of optional add-on operating system components for such high-level services as file system organization, network communication, network management, database management, user-interface graphics, etc. Although many of these add-on components are much larger and much more complex than the RTOS kernel, they rely on the presence of the RTOS kernel and take advantage of its basic services. Each of these add-on components is included in an embedded system only if its services are needed for implementing the embedded application, in order to keep program memory consumption to a minimum.

In this paper, we will focus on the basic RTOS kernel services for task management, intertask communication and synchronization, and dynamic memory allocation.

RTOSs vs. general-purpose operating systems

Many non-real-time operating systems also provide similar kernel services. The key difference between general-computing operating systems and real-time operating systems is the need for " deterministic " timing behavior in the real-time operating systems. Formally, "deterministic" timing means that operating system services consume only known and expected amounts of time. In theory, these service times could be expressed as mathematical formulas. These formulas must be strictly algebraic and not include any random timing components. Random elements in service times could cause random delays in application software and could then make the application randomly miss real-time deadlines – a scenario clearly unacceptable for a real-time embedded system.

General-computing non-real-time operating systems are often quite non-deterministic. Their services can inject random delays into application software and thus cause slow responsiveness of an application at unexpected times. If you ask the developer of a non-real-time operating system for the algebraic formula describing the timing behavior of one of its services (such as sending a message from task to task), you will invariably not get an algebraic formula. Instead the developer of the non-real-time operating system (such as Windows, Unix or Linux) will just give you a puzzled look. Deterministic timing behavior was simply not a design goal for these general-computing operating systems.

On the other hand, real-time operating systems often go a step beyond basic determinism. For most kernel services, these operating systems offer constant load-independent timing: In other words, the algebraic formula is as simple as: T(message_send) = constant , irrespective of the length of the message to be sent, or other factors such as the numbers of tasks and queues and messages being managed by the RTOS.

Task scheduling

Most RTOSs do their scheduling of tasks using a scheme called "priority-based preemptive scheduling." Each task in a software application must be assigned a priority, with higher priority values representing the need for quicker responsiveness. Very quick responsiveness is made possible by the "preemptive" nature of the task scheduling. "Preemptive" means that the scheduler is allowed to stop any task at any point in its execution, if it determines that another task needs to run immediately.

The basic rule that governs priority-based preemptive scheduling is that at every moment in time, "The Highest Priority Task that is Ready to Run, will be the Task that Must be Running." In other words, if both a low-priority task and a higher-priority task are ready to run, the scheduler will allow the higher-priority task to run first. The low-priority task will only get to run after the higher-priority task has finished with its current work.

What if a low-priority task has already begun to run, and then a higher-priority task becomes ready? This might occur because of an external world trigger such as a switch closing. A priority-based preemptive scheduler will behave as follows: It will allow the low-priority task to complete the current assembly-language instruction that it is executing. [But it won’t allow it to complete an entire line of high-level language code; nor will it allow it to continue running until the next clock tick.] It will then immediately stop the execution of the low-priority task, and allow the higher-priority task to run. After the higher-priority task has finished its current work, the low-priority task will be allowed to continue running. This is shown in Figure 3, where the higher-priority task is called "Mid-Priority Task."

Of course, while the mid-priority task is running, an even higher-priority task might become ready. This is represented in Figure 3 by "Trigger_2" causing the "High-Priority Task" to become ready. In that case, the running task ("Mid-Priority Task") would be preempted to allow the high-priority task to run. When the high-priority task has finished its current work, the mid-priority task would be allowed to continue. And after both the high-priority task and the mid-priority task complete their work, the low-priority task would be allowed to continue running. This situation might be called "nested preemption."

Figure 3: Timeline for Priority-based Preemptive Scheduling Examples

Each time the priority-based preemptive scheduler is alerted by an external world trigger (such as a switch closing) or a software trigger (such as a message arrival), it must go through the following 5 steps:

* Determine whether the currently running task should continue to run. If not …
* Determine which task should run next.
* Save the environment of the task that was stopped (so it can continue later).
* Set up the running environment of the task that will run next.
* Allow this task to run.

These 5 steps together are called "task switching."

Fixed-time task switching

The time it takes to do task switching is of interest when evaluating an operating system. A simple general-computing (non-preemptive) operating system might do task switching only at timer tick times, which might for example be ten milliseconds apart. Then if the need for a task switch arises anywhere within a 10-millisecond timeframe, the actual task switch would occur only at the end of the current 10-millisecond period. Such a delay would be unacceptable in most real-time embedded systems.

In more sophisticated preemptive task schedulers, the scheduler may need to search through arrays of tasks to determine which task should be made to run next. If there are more tasks to search through, the search will take longer. Such searches are often done by general-computing operating systems, thus making them non-deterministic. Real-time operating systems, on the other hand, avoid such searches by using incrementally updated tables that allow the task scheduler to identify the task that should run next in a rapid fixed-time fashion.

These two types of timing behavior for task switching can be seen in Figure 4.

Figure 4: Task Switching Timing

In this figure, we see that for a general-computing (non-real-time) operating system, the task switching time generally rises as a software system includes more tasks that can be scheduled. However, the actual time for a task switch is not the time shown by the dashed red line. Instead, in any given task switch instance, it might be well above or well below the time shown by the dashed red line. The shaded regions surrounding the dashed red line simply show the likelihood of the actual task switch time being that far above or below the dashed red line.

On the other hand, the horizontal solid green line shows the task switching time characteristic of a real-time operating system. It is constant, independent of any load factor such as the number of tasks in a software system.

Please note that in some instances, such as the leftmost area of the graph, the task switching time might in special cases be quicker for a general-computing non-real-time operating system, than for a real-time operating system. This does not detract from the appropriateness of a real-time operating system for real-time embedded applications. For, in fact, the term "real-time" does not mean "as fast as possible" but rather "real-time" demands consistent, repeatable, known timing performance. Although a non-real-time operating system might do some faster task switching for small numbers of tasks, it might equally well introduce a long time delay the next time it does the same task switch. The strength of a real-time operating system is in its known, repeatable timing performance, which is also typically faster than that of a non-deterministic task scheduler in situations of large numbers of tasks in a software system. Most often, the real-time operating system will exhibit task-switching times much faster than its non-real-time competitor when the number of tasks grows above 5 or 10.

Intertask communication and synchronization

Most operating systems, including RTOSs, offer a variety of mechanisms for communication and synchronization between tasks. These mechanisms are necessary in a preemptive environment of many tasks, because without them the tasks might well communicate corrupted information or otherwise interfere with each other.

For instance, a task might be preempted when it is in the middle of updating a table of data. If a second task that preempts it reads from that table, it will read a combination of some areas of newly-updated data plus some areas of data that have not yet been updated. [New Yorkers would call this a "mish-mash."] These updated and old data areas together may be incorrect in combination, or may not even make sense. An example is a data table containing temperature measurements that begins with the contents "10 C." A task begins updating this table with the new value "99 F", writing into the table character-by-character. If that task is preempted in the middle of the update, a second task that preempts it could possibly read a value like "90 C" or "99 C." or "99 F", depending on precisely when the preemption took place. The partially updated values are clearly incorrect, and are caused by delicate timing coincidences that are very hard to debug or reproduce consistently.

An RTOS's mechanisms for communication and synchronization between tasks are provided to avoid these kinds of errors. Most RTOSs provide several mechanisms, with each mechanism optimized for reliably passing a different kind of information from task to task.

Probably the most popular kind of communication between tasks in embedded systems is the passing of data from one task to another. Most RTOSs offer a message passing mechanism for doing this, as seen in Figure 5. Each message can contain an array or buffer of data.

Figure 5: Intertask Message Communication

If messages can be sent more quickly than they can be handled, the RTOS will provide message queues for holding the messages until they can be processed. This is shown in Figure6.

Another kind of communication between tasks in embedded systems is the passing of what might be called "synchronization information" from one task to another. "Synchronization information" is like a command, where some commands could be positive, and some negative. For example, a negative command to a task would be something like "Please don’t print right now, because my task is using the printer." Or more generally, "I want to lock the . . . for my own use only." A positive command would be something like "I’ve detected a cardiac emergency, and I want you to help me handle it." Or more generally, "Please join me in handling . . ."

Most RTOSs offer a semaphore or mutex mechanism for handling negative synchronization (sometimes called "mutual exclusion"). These mechanisms allow tasks to lock certain embedded system resources for their use only, and subsequently to unlock the resource when they’re done.

For positive synchronization, different RTOSs offer different mechanisms. Some RTOSs offer event-flags, while others offer signals. And yet others rely on message passing for positive synchronization as well as data passing duties.

Determinism and high-speed message passing

Intertask message communication is another area where different operating systems show different timing characteristics. Most operating systems actually copy messages twice as they transfer them from task to task via a message queue. See Figure 6. The first copying is from the message-sender task to an operating system-owned "secret" area of RAM memory (implementing the "message queue"); and the second copying is from the operating system’s "secret" RAM area to the message-receiver task. Clearly this is non-deterministic in its timing, as these copying activities take longer as message length increases.

Figure 6: Message Transfer via Message Queue

An approach that avoids this non-determinism and also accelerates performance, is to have the operating system copy a pointer to the message and deliver that pointer to the message-receiver task without moving the message contents at all. In order to avoid access collisions, the operating system then needs to go back to the message-sender task and obliterate its copy of the pointer to the message. For large messages, this eliminates the need for lengthy copying and eliminates non-determinism.

Dynamic memory allocation

Determinism of service times is also an issue in the area of dynamic allocation of RAM memory. Many general-computing non-real-time operating systems offer memory allocation services from what is termed a "Heap." The famous "malloc" and "free" services known to C-language programmers work from a heap. Tasks can temporarily borrow some memory from the operating system’s heap by calling "malloc", and specifying the size of memory buffer needed. When this task (or another task) is finished with this memory buffer it can return the buffer to the operating system by calling "free." The operating system will then return the buffer to the heap, where its memory might be used again, perhaps as part of a larger buffer. Or perhaps it may in the future be broken into several smaller buffers.

Heaps suffer from a phenomenon called "External Memory Fragmentation" that may cause the heap services to degrade. This fragmentation is caused by the fact that when a buffer is returned to the heap, it may in the future be broken into smaller buffers when "malloc" requests for smaller buffer sizes occur. After a heap undergoes many cycles of "malloc"s and "free"s, small slivers of memory may appear between memory buffers that are being used by tasks. These slivers are so small that they are useless to tasks. But they are trapped between buffers that are being used by tasks, so they can’t be coagulated ("glued") together into bigger, useful buffer sizes. Over time, a heap will have more and more of these slivers. This will eventually result in situations where tasks will ask for memory buffers ("malloc") of a certain size, and they will be refused by the operating system --- even though the operating system has enough available memory in its heap. The problem: That memory is scattered in small slivers distributed in various separate parts of the heap. In operating system terminology, the slivers are called "fragments", and this problem is called "external memory fragmentation."

This fragmentation problem can be solved by so-called "garbage collection" (defragmentation) software. Unfortunately, "garbage collection" algorithms are often wildly non-deterministic – injecting randomly-appearing random-duration delays into heap services. These are often seen in the memory allocation services of general-computing non-real-time operating systems.

This puts the embedded system developer who wants to use a general-computing non-real-time operating system into a quandry: Should the embedded system be allowed to suffer occasional randomly-appearing random-duration delays if / when "garbage collection" kicks in?... Or, alternatively, should the embedded system be allowed to fragment its memory until application software "malloc" requests to the heap are refused even though a sufficient total amount of free memory is still available? Neither alternative is acceptable for embedded systems that need to provide service continually for long periods of time.

Real-time operating systems, on the other hand, solve this quandry by altogether avoiding both memory fragmentation and "garbage collection", and their consequences. RTOSs offer non-fragmenting memory allocation techniques instead of heaps. They do this by limiting the variety of memory chunk sizes they make available to application software. While this approach is less flexible than the approach taken by memory heaps, they do avoid external memory fragmentation and avoid the need for defragmentation. For example, the "Pools" memory allocation mechanism allows application software to allocate chunks of memory of perhaps 4 or 8 different buffer sizes per pool. Pools totally avoid external memory fragmentation, by not permitting a buffer that is returned to the pool to be broken into smaller buffers in the future. Instead, when a buffer is returned the pool, it is put onto a "free buffer list" of buffers of its own size that are available for future re-use at their original buffer size. This is shown in Figure 7.

Figure 7: A Memory Pool's Free Buffer Lists

Memory is allocated and de-allocated from a pool with deterministic, often constant, timing.

Summary

Real-time and embedded systems are used in many applications such as airborne computers, medical instruments and communication systems. Embedded systems are characterized by limited processor memory, limited processing power, and unusual interfaces to the outside world. Real-time requirements impose stringent time deadlines for delivering the results of embedded processing.

RTOS kernels hide from application software the low-level details of system hardware, and at the same time provide several categories of services to application software. These include: task management with priority-based preemptive scheduling, reliable intertask communication and synchronization, non-fragmenting dynamic memory allocation, and basic timer services.

The issue of timing determinism is important in differentiating general-computing operating systems from real-time operating systems. This issue crops up in many parts of operating system kernels, such as task schedulers, dynamic memory allocation and intertask message communication. While general-computing operating systems often offer non-deterministic services in these areas, fully deterministic solutions are needed for real-time and embedded systems. A number of real-time operating systems implement these solutions in their compact high-performance kernels.

Nuclear Reactor ......Do u know..

2009-02-21T23:31:00.000-08:00

2009-02-21T22:26:00.000-08:00