Posix Shared memory with linked list

[sjaiswal]

Hi

I want to implement a work queue using posix shared memeory so that it can be shared between process.

i like implement function such as

1. queue_put(node) that add a node ( having all the information about a task) into the shared memeory.
2. queue_get() so that i get the root node of the list . also this node should get deleted after get.

can some one help me in this

Thanks

[wje_lf]

It's unlikely that someone here will design the code for you, but we'll probably be glad to help if you have a question about a particular detail of code you've already written.

For information about linked lists, go here.

If you're going to be using linked lists in shared memory, you'll face an additional problem. If more than one process is using the shared memory, the pointers might not work from one process to the next. That's because different processes might have the shared memory at different places in their respective address spaces. That might or might not happen. Murphy's Law says that your program won't encounter this problem while you're testing it, but will encounter it the first time your customer tries to run it.

There's another consideration. Is there any chance that your program will die before being able to deallocate the shared memory? If so, you will accumulate orphaned shared memory segments, and eventually the system will refuse to give you a new one. That is usually fixed by rebooting the system, but you really want to avoid the situation in the first place. In that case, you may wish to avoid POSIX shared memory; there are other ways to go on this.

[sjaiswal]

so what cud be the best way to share information between process. One process is producer and others are consumer( of information about the task).

how can i design that producer don't have to bother to inform consumer that pick up the job. producer simply puts the job in some shared place and consumer picks them up.

[wje_lf]

You could put the information in a file: not one file for each item produced, but one overall file for all of them. Use advisory record locking to make sure that one process is not reading the file while another is changing it. Also use advisory record locking as a way to allow consumers to wait until a new item is available for consumption.

[sjaiswal]

producer will produce the job in bulk/batch and write them at once there in the file.
afte this consumer will start reading. so how will assure when once a job is picked it is not picked up by other files. I mean how it entry will get deleted from file???


Instead of using the advisory record locking can't semaphore is used. each time i add itmes/task , sem_signal will be issued. and make each process wait on sem_wait. also another binary/mutex semaphore cud be used in addtion so that only one process read at a time.

[wje_lf]

producer will produce the job in bulk/batch and write them at once there in the file.
afte this consumer will start reading. so how will assure when once a job is picked it is not picked up by other files. I mean how it entry will get deleted from file???

Any process which wants to change the file should use an advisory writer's lock. Any process which wants to read the file should use an advisory reader's lock on the same byte of the file. This assures that nobody is reading while the file is being modified. To delete the entry, simply rewrite the whole file without that entry.

Instead of using the advisory record locking can't semaphore is used.

POSIX semaphores have the same problem as shared memory. Suppose the process responsible for creating a semaphore dies without releasing that semaphore. Over time, you will accumulate orphaned semaphores, and eventually the system will refuse to give you a new one. That is usually fixed by rebooting the system, but you really want to avoid the situation in the first place.

Perhaps you're using non-POSIX semaphores; I don't have functions such as sem_wait() and sem_signal() on my system. If they're not just wrappers for POSIX semaphores, then it's up to you to determine whether you have the same problem of orphaned semaphores in the event of a crashed application. :)

[sjaiswal]

But the process that will be creating the semaphore will not die. Only case cud be that process dies/killed by parent holding the lock(mutex) on semaphore. so will other process be able to unlock it or not?? are posix semaphore reliable in such cases ???

How can advisory record locks be usefull in such cases??. If program dies holding advisory write lock then will it be able to recover in such situations??

[wje_lf]

But the process that will be creating the semaphore will not die.

If you're willing to take that risk, then use semaphores. Just be aware of the risk.

How can advisory record locks be usefull in such cases?

See this link for information on how to use advisory record locking. Use it as you'd use a semaphore.

If program dies holding advisory write lock

... then the lock is immediately and automatically released.

[sjaiswal]

Will advisory locks can take care of starvation ??

[wje_lf]

Will advisory locks can take care of starvation ?

Not automatically, no. That's an overall synchronization issue that you must handle in your design, no matter what synchronization mechanism you use.