Re: Swapping and IPC

From: Jean-David Beyer (jdbeyer_at_exit109.com)
Date: 12/01/04 

Date: Wed, 01 Dec 2004 10:12:21 -0500

Matthias wrote:
> Hi there,
>
> my OS book (Tanenbaum)

IIRC, that is a very old book.

> is telling me that IPC is impossible when using
> a swapping mechanism. For him the term 'swap' just says that the
> complete process is being moved out - not just a part as with paging
> or segmentation. So one has to be careful to not mix those techniques
> up.
>
> My q. is: Why is IPC not working? Suppose I'm sending a request to a
> swapped-out process isn't it so that the os is trapping my request and
> swapping in the desired process to let it receive my message?

I do not know how Linux does it, but SVID 3.2 or whatever it was did it
just fine. Associated with each process that had IPC enabled was a queue
in the kernel dataspace somewhere. When you sent a message to a process,
it went into that queue. The next time the receiving process got into
memory and started running, it could pick up its messages from the queue.
So the whole thing, in those days, would be a non-issue.

An important issue was what happened if you sent a message to a queue that
was full? IIRC, the sending process could arrange for the s.p. to be
suspended until there was room in the r.p.'s input queue, or it could
arrange to get an error return. You could deadlock the system if you did
not know what you were doing.
>
> The same is true for paging. Ok, the page boundaries fall arbitrary
> but is this a problem of mine? I'm not sending messages to pages
> rather then to processes. So why is he saying that IPC makes serious
> problems when using paging?

These days, I imagine a better way than System V ipc messaging would be to
just use TCP/IP. That way, if you ever needed to split your software
system over more than one hardware system, it would keep on working. In
any case, I do not think it much of an issue. I wonder what Tanenbaum was
thinking of.

I designed the IPC for a system running hundreds of processes exchanging
messages. Each process was a finite state machine. Lots of messages were
exchanged and we had to do a lot to ensure the messaging system did not
deadlock. But normally, the time to process a message was long compared to
the time to send and receive one, so it was not very important to the
throughput of the entire system.
>
> Hope one of you guys can help answering my questions. Thanks for
> reading! 

-- 
   .~.  Jean-David Beyer           Registered Linux User 85642.
   /V\                             Registered Machine   241939.
  /( )\ Shrewsbury, New Jersey     http://counter.li.org
  ^^-^^ 10:05:00 up 39 days, 13:00, 3 users, load average: 4.34, 4.29, 4.27

Relevant Pages

  • Re: cgi concurrency approaches?
    ... Here is a brief page about System V IPC ... a python interface to System V IPC facilities, ... Use a dedicated Queue, and hold the counter value inside a single ... Store the value in pre-created shared memory partition, ...
    (comp.lang.python)
  • Re: Can extra processing threads help in this case?
    ... MQ is because multiple processes require IPC. ... four separate OCR processes using some sort of FIFO queue, ... and in an implementaiton, a FIFO queue for IPC ...
    (microsoft.public.vc.mfc)
  • Re: Wait for Multiple objects
    ... Yes, what you're attempting is possible, and a common way to implement IPC. ... But just curious to know why NOPRECOMMIT flag didnt ... same queue and read the message i posted. ...
    (microsoft.public.windowsce.embedded)
  • Re: IPC in C#
    ... I mean IPC as an inter process messages queueing mechanism. ... Answer messages use the same mechanism (in another queue ?) ... >> A first version has been written, using Tcp sockets (1 thread by ...
    (microsoft.public.win32.programmer.networks)
  • Re: threads and log
    ... memory are constantly transferred between the threads. ... I cannot remember results of performance testing wrt per-thread queue vs. global queue. ... IIRC, log entries were frequent in some cases; I did not want to take a lock for each one. ...
    (comp.programming.threads)