Linked by nfeske on Thu 26th May 2011 11:41 UTC
Thread beginning with comment 474805
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Best approach is shared memory buffers.
by axilmar on Fri 27th May 2011 16:31
in reply to "RE: Best approach is shared memory buffers."
Isn't the semaphore also a kernel-provided mechanism, which forces both processes to synchronize via kernel entries?
It doesn't have to be a kernel object.
Also, the usage of a shared-memory communication comes not for free as one has to establish the shared memory with each communication partner
Not a problem. The virtual memory subsystem can take care of that.
allocate buffers in the shared memory
Can be done via mutexes (not kernel objects) in shared memory.
acknowledge completed messages for buffer reuse
The buffers are simply freed from the shared memory.
maybe unblock the sender that wants to marshal the next message
Atomically increment the semaphore. If the other CPU spins on the semaphore (i.e. it's a spin lock), then the other process will be unblocked.
Modern microkernels like Fiasco.OC support fast inter-process communication with a user-level accessible part of the thread control block - UTCB - with a size of about 64 register words or something more. Processes marshal their message payload into the UTCB, the kernel copies from sender to receiver UTCB, and, finally, the receiver demarshals the data out of the UTCB as needed. Performance-wise this should fit the approach you described, the time for the copy operation is bounded by UTCB size, and there's no shared-memory establishment overhead as only the kernel accesses both UTCBs.
The 80x86 CPU doesn't have 64 registers available for users. Furthermore, you still do two kernel switches. I think the shared memory approach is faster, at least on 80x86.




Member since:
2008-08-11
Isn't the semaphore also a kernel-provided mechanism, which forces both processes to synchronize via kernel entries? Also, the usage of a shared-memory communication comes not for free as one has to establish the shared memory with each communication partner, allocate buffers in the shared memory, maybe allocate control packets, acknowledge completed messages for buffer reuse and maybe unblock the sender that wants to marshal the next message. From our experience with Genode, this pays off for bulk-data transfer but not for most RPCs with just a few register words of payload.
Modern microkernels like Fiasco.OC support fast inter-process communication with a user-level accessible part of the thread control block - UTCB - with a size of about 64 register words or something more. Processes marshal their message payload into the UTCB, the kernel copies from sender to receiver UTCB, and, finally, the receiver demarshals the data out of the UTCB as needed. Performance-wise this should fit the approach you described, the time for the copy operation is bounded by UTCB size, and there's no shared-memory establishment overhead as only the kernel accesses both UTCBs.