SHMOP (SYSV) - really shmat(2)

[Robert Bradbury]

>From Roger Noe:

> But what worries me is that the (char *)(-1) might be a legitimate value for
> a pointer to a character.  I think only NULL is required by the language to
> never point to anything.  The bit pattern for (char *)(-1) could conceivably
> be indistinguishable from a successful return value.  Why is this not NULL?
> Because little minds stuck to their foolish consistency that all system calls
> should return -1 upon failure.  What they forgot was that all system calls
> should return integers!  shmat() in particular should have been allowed
> another argument, type (char **) in which one could pass &cp.

>From the XJ311 C Standard, C.2.2.3:
	"The integer constant 0 is converted to a pointer of the
	appropriate type that is guranteed not to point to an OBJECT.
	Such a pointer, called a null pointer, must appear to be equal to the
	integer constant 0.".
>From D.1.1:
	"NULL ... [can be used] as an argument to represent the null pointer".

It is highly questionable whether the result of shmat() can be considered
to point to an "OBJECT", so it may be perfectly allowable from a C standard
point of view to return NULL.  I can imagine machines (I&D space PDP11s)
where you could detach your data space and attach a shared memory segment
at location zero, so NULL (or 0) is a reasonable result from shmat().

At the same time the result of shmat() must be on a SHMLBA boundary.
Out of the 8 or so machines we have used this on, the smallest boundary
I've seen is a 512 byte boundary, so although (char *)-1 may be a pointer
to a character, it is not a legal result from shmat() and may thus be used
to indicate failure of the system call.

> The interprocess communication primitives included in System V (message
> queues, semaphores, and shared memory) are all very messed up.  They were
> clearly not thought out too well in either their design or implementation.
> With any luck, they'll go away soon and be replaced by something that works.
> 

Are they really that messed up?  What criteria do you use to judge that?

We have used all of the calls (shared memory, messages and semaphores)
in implementations of Oracle running on a number of machines.  As articles
at the most recent USENIX, UNIX Review (8/85) and the Bell System Technical
Journal (11/82) indicate, they are critical to the implementation of high
performance DBMS packages [and good multi-user real-time games :-)].

If you were to take a look at shared memory implentations on other operating
systems (VM, MVS, VMS, AOS, etc), you might find that the UNIX facilities are
not all that bad.

My complaints with these calls would be:
 a) The documentation for semaphores is unintelligable, but if you can
    figure them out they work much better than using a signal/kill
    mechanism.  I think the basic problem is that the call is overloaded.
 b) The manufacturers do not test the calls.  We have found bugs (historically)
    in releases from AT&T (3B20,3B2), Amdahl (UTS), and Pyramid.
 c) If you could tell when a process associated with a message queue died
    (via a signal), you could use messages to replace pipes (they are more
    efficient).  Using an alarm() with a msgget() adds too much overhead.
 d) You never know where you can attach shared memory segments if you want
    to put them at fixed addresses.  You have to use test programs
    to determine the valid addresses because they aren't documented.
    The difference in location and direction of growth of shared memory
    segments on two supposadly identical machines (the 3B2 and 3B5)
    is a joke!  [However, this is a problem with AT&T's hardware and software
    people not talking to each other -- not a problem with shared memory.]

As far as going away, I sure hope not -- they are in the System 5 Interface
Definition.  And they really do work (despite Roger's comments).
Now, if the Berkeley people would only wake up and put them into 4.3 or 4.4
life would be just great :-).
-- 
Robert Bradbury
Oracle Corporation
(206) 364-1442                            {ihnp4!muuxl,hplabs}!oracle!bradbury