Re: How to implement synchronous rpc between 2 processes on the same machine.

On Sep 22, 8:20 am, "Chris M. Thomasson" <n...@xxxxxxxxxxxx> wrote:
"lali.cpp" <lali....@xxxxxxxxx> wrote in message

news:478d5717-1233-42eb-b6a9-a5be184d414a@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



Hi

I hope i have not posted at the wrong place. Kindly read the full post
before lamenting as off topic:

Basically i need functionality similar to that provided by Solaris
DOORS( it is a properietry and quite efficient IPC by SUN)
To explain it:

I have process p1 and process p2 on the same computer and i can call a
function foo( ) in process p2 from p1 i.e rpc( on the same host) using
the function door_call( which takes arguments and writes and

This function door_call is synchronous. Moreover the DOOR library
makes sure that the function f( ) is executed in a concurrent manner
i.e it internally maintains a pool of threads i.e the server( process
p2 is a concurrent server )

So thats all about my requirement. I cannot use DOORS because i am now
porting the project to Linux.

So here is my design the i want you to kindly kindly review and give
me lots of details, caveats, shortcomings, suggestions etc as i am not
very well good in multithreaded programming and would like to have
your guidance rather that implement something that takes a lot of
locks and generates a lot of threads but is essentially serialized
code and add to it the problem of deadlocks and races. I need
efficiency and scalability in design and so require you geeks out
there to just review this design and provide your much needed inputs.

[...]

Read here for some tips on how to implement dynamically created shared
memory:

http://groups.google.com/group/comp.programming.threads/browse_frm/th...

One caveat... How are you going to handle a scenario in which a process gets
terminated while it holds a mutex? How much you do know about robust mutexs?
The link above deals with some of that. I have created impls of something
that is basically analogous to Solaris Doors. Perhaps I can help you. Its
not easy in any sense of the term indeed. However, its doable. You need to
think  about how your going to handle the "robustness" factor first.
Multi-process shared memory impls need to think about misbehaving process..
Before I go on and on, do you have any thoughts on this aspect?


Well i have read a little about boost::thread library and we have a
non-blocking timed mutex in there. So instead of having a blocking
mutex we could use the boost::timedmutex.

In my particular case, let me elaborate the kind of functionality i
need. Process p1 wants to call a function say my_door(arguments). This
function will be executed in process 2 and results will be written to
the buffer sent by process 1 in the arguments to my_door.

I am not saying i need shared memory, all i am saying is what would be
the *best* way to do( doesn't matter using shared memory, message
queues or any other ipc mechanism). But the most important thing is
that multiple threads from p1 can call my_door( ) function and all the
requests are executed *concurrently* on the server side. Second
requirement is my_door( ) call is synchronous i.e blocking i.e just
like door_call in solaris. ( Of course the application makes sure that
the function being executed is thread safe )


Here is something i have thought and i need your suggestions :
We can have 2 queues say q1 and q2 in the shared memory and both the
processes have a dedicated thread each listening at these queues i.e
process p1 has a thread checking to see if p2 has written something on
q1 and p2 has a thread listening to q2 to check if p1 wrote something
in q2.


These respective threads can then distribute the remaining work to
worker threads in the respective threads.

this is just a vague idea but how would i make the door_call
synchronous ? the thread in p1 would just write the arguments in q2
and return ?

And i also need some suggestions whether the above design would be
fine or not ? Or does it suck just like my earlier design in the last
post( don't read it anyway )


Thanks & Regards
lali.cpp

.

Relevant Pages

  • Re: Gracefully shutting down a thread in a DLL
    ... This is a classic case of broken by design;) ... The fact that your shared memory structure requires this type of metadata to ... we sell an API that lives in a DLL. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: event driven paradigm
    ... This last paragraph sounds like you are confusing threads and processes. ... If you have a multi-process model, then the sockets or pipes with ... In contrast to your assumption of my "shared memory" ... creating a mutex per thread and signal the mutex to wake up each thread ...
    (comp.programming.threads)
  • Re: PTHREAD_PROCESS_SHARED on GNU/Linux
    ... a stock Linux kernel won't release the lock on behalf of the ... mutex, so you'd probably have to stop everything and re-initialize the ... shared memory if any process dies unexpectedly. ... If a process dies unexpectedly while holding a mutex, ...
    (comp.programming.threads)
  • Re: Shared-memory between threads and synchronization
    ... In my project i am having different data structures ... process and shared memory should be accessed between different ... co-ordinate activities just through a mutex. ... If the scheduled thread doesnt need the mutexed resource, ...
    (comp.os.linux.development.system)
  • Re: Shared Memory for Application/Communication decoupling
    ... Right now we are doing a new design and therefore we are evaluating new design options which will allow us to support different fieldbus protocol in the feature. ... For interrupt handlers, the interrupt code may typically transfer data into a queue, with the mainline process reading the queue. ... From this point of view it is bad the the communication task and the application task use a low level primitive like shared memory. ...
    (comp.arch.embedded)