Group Name:A
Entitled Project:PIPE SERVER USING PIPES on stand-alone system
Mentor:Varun Sir
Captain:Pushpa
Team members:Satish,Dharmendra,Paras,Pushpa
Project progress details:
We have implemented the basic communication between single client & server through pipe today.
Great
We implemented the client server through pipe as well as fifo.
I would like to share my learning while creating client server pgm through PIPES.
We made a mistake by creating a single pipe and communicated between client1 & server & the client2 (which has the solution).We need to create two separate pipes and then establish the communication between client & server.
I am sharing my learning so that noone else should commit the same mistake.
Thanks
can anyone guide me the basic implementation difference between a counting semaphore & binary semaphore.
Binary Semaphores
A binary semaphore is a synchronization object that can have only two states:
*
Not taken.
*
Taken.
Two operations are defined:
*
Taking a binary semaphore brings it in the “taken” state, trying to take a semaphore that is already taken enters the invoking thread into a waiting queue.
*
Release . Releasing a binary semaphore brings it in the “not taken” state if there are not queued threads. If there are queued threads then a thread is removed from the queue and resumed, the binary semaphore remains in the “taken” state. Releasing a semaphore that is already in its “not taken” state has no effect.
Binary semaphores have no ownership attribute and can be released by any thread or interrupt handler regardless of who performed the last take operation. Because of this binary semaphores are often used to synchronize threads with external events implemented as ISRs, for example waiting for a packet from a network or waiting that a button is pressed.
Because there is no ownership concept a binary semaphore object can be created to be either in the “taken” or “not taken” state initially.
Counting Semaphores
A counting semaphore is a synchronization object that can have an arbitrarily large number of states. The internal state is defined by a signed integer variable, the counter. The counter value (N) has a precise meaning:
*
Negative, there are exactly -N threads queued on the semaphore.
*
Zero, no waiting threads, a wait operation would put in queue the invoking thread.
*
Positive, no waiting threads, a wait operation would not put in queue the invoking thread.
Two operations are defined for counting semaphores:
*
Wait . This operation decreases the semaphore counter, if the result is negative then the invoking thread is queued.
*
Signal .This operation increases the semaphore counter, if the result is non-negative then a waiting thread is removed from the queue and resumed.
Counting Semaphores states diagram
Counting semaphores have no ownership attribute and can be signaled by any thread or interrupt handler regardless of who performed the last wait operation.
Because there is no ownership concept a counting semaphore object can be created with any initial counter value as long it is non-negative.
The counting semaphores are usually used as guards of resources available in a discrete quantity. For example the counter may represent the number of used slots into a circular queue, producer threads would “signal” the semaphores when inserting items in the queue, consumer threads would “wait” for an item to appear in queue, this would ensure that no consumer would be able to fetch an item from the queue if there are no items available.
A mutex is a synchronization object that can have only two states:
*
Not owned.
*
Owned.
Two operations are defined for mutexes:
*
Lock . This operation attempts to take ownership of a mutex, if the mutex is already owned by another thread then the invoking thread is queued.
*
Unlock . This operation relinquishes ownership of a mutex. If there are queued threads then a thread is removed from the queue and resumed, ownership is implicitly assigned to the thread.
Mutexes states diagram
Note that, unlike semaphores, mutexes do have owners. A mutex can be unlocked only by the thread that owns it, this precludes the use of mutexes from interrupt handles but enables the implementation of the Priority Inheritance protocol.
Mutexes have one single use, Mutual Exclusion, and are optimized for that. Semaphores can also handle mutual exclusion scenarios but are best used as a communication mechanism between threads or between ISRs and threads.
This is paras , dharmendra , harpreet ; we have tried to implement semaphore with the help process using do-while , while & all other conditions in server ; we also use wait system call in parent process in server ; but not able to get desired results ……so please provide us solution to this problem as soon as possible………..
What you people will do is
1 Create the named semaphore and set it in a locked state
2 Launch the server
3 Wait for the FIFO’s to be visible at the file-system level
4 Open fifo1 for writing (non-blocking)
5 Open fifo2 for reading (blocks until the server opens fifo2 for writing)
6 Wait on the semaphore (possibly with a timeout) until the server unlocks it, indicating that it has now opened both FIFO’s successfully.
In the server:
1 Create the FIFO’s
2 Open fifo1 (blocks until the client opens it for writing)
3 Open fifo2 (non-blocking)
4 Unlock the semaphore now that the server has opened both FIFO’s
This is paras , dharmendra , harpreet ; we have tried to implement semaphore with the help process using do-while , while & all other conditions in server ; we also use wait system call in parent process in server ; but not able to get desired results ……so please provide us solution to this problem as soon as possible……………
This is paras , dharmendra , harpreet ; we have tried to implement semaphore with the help process using do-while , while & all other conditions in server ; we also use wait system call in parent process in server ; but not able to get desired results ……so please provide us solution to this problem as soon as possible……….. ….
If a process attempts to read from an empty pipe, then read will block until data is available.so i think the server should wait untill some data is available on fifo.may be we are doing the mistake by closing the read fd of the server inside while loop.
i understand that we shouldnt put open fifo inside the while loop & should close this fd after while loop.
i m unable to implement the semaphore in my system.so i m struck.i dont understand why the same settings of semget & semctl is nt working in my system.
@varun sir:i read this doc..bt still i m nt getting a clear picture.plz help me to analyze it in a better way
what i found on your program is that you were using struct sembuf globally and is common to sem_p and sem_v. Try using different struct sembuf variables in the sem_p function and sem_v function seperately.
I have implement basic client server model by message queue, work on the higher level
I have implement the final client server project with message queue but there is little problem my server show abrupt behaviour.Some times its give only signal result , some time two from all