🚀 go-pugleaf

"Eugene Mayevski [SecureBlackbox]" <mayevski@eldos.org> wrote:

>Not just easily, but extremely easily. Part of this shared block becomes 
>a common variable which is accessed and changed using 
>InterlockedIncrement() and similar APIs. The rest is used for data 
>exchange. And you don't need mutexes and WaitFor* to do the exchange.

Ah, so you're layering something on top, and looking for it to change.

An analogy.

Let's suppose I have a friend, but he and I must never be seen together.
(We're different processes running under Win32.) But we do both have the
keys to a lock-up storage unit. (We both can see the same shared
memory.)

Now I want him to give me a steamer trunk full of stuff. I could go down
to the storage unit every day, and see if he's put it there yet. If it's
not there, I chalk a note inside the door, and hope he looks soon. (We
both look at the common variable.)

On the other hand, I could ring him on his mobile phone and get him to
put it there at once.

The communication side of things is akin to ringing his mobile. It would
use something like a named pipe, and should be much more efficient,
since the thread receiving the message wouldn't spend its entire time
locking and unlocking the same variable just to see if it had changed.

(I assume by the way that you meant InterlockedIncrementAcquire, since
InterlockedIncrement itself doesn't not mention cross-process locking.)

Alan Bellingham
-- 
ACCU Conference 2005 - 20-23 April, Randolph Hotel, Oxford, UK