From owner-freebsd-hackers  Tue Feb 16 17:27:18 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10])
	by hub.freebsd.org (Postfix) with ESMTP id 905001136A
	for <hackers@FreeBSD.ORG>; Tue, 16 Feb 1999 17:26:59 -0800 (PST)
	(envelope-from peter.jeremy@AUSS2.ALCATEL.COM.AU)
Received: by border.alcanet.com.au id <40408>; Wed, 17 Feb 1999 12:16:02 +1100
Date: Wed, 17 Feb 1999 12:26:51 +1100
From: Peter Jeremy <peter.jeremy@AUSS2.ALCATEL.COM.AU>
Subject: Semaphore handling
To: hackers@FreeBSD.ORG
Message-Id: <99Feb17.121602est.40408@border.alcanet.com.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

About Friday there was a thread covering semop(2) behaviour.  As I
mentioned, I'm looking through the current code (and man pages) [at a
slower rate than I hoped] and trying to make them align to The Open
Group's `Single Unix Specification, version 2'
(http://www.opengroup.org/onlinepubs/7908799/).

In the process, I've found a few anomolies which I'd like some input
on before I implement them:

1) What are the rules regarding the use of gcc extensions in the
   kernel?  (This doesn't appear to be mentioned in style(9)).
   Background: semop() currently uses the macro MAX_SOPS to specify
   the maximum number of sem_op's it can process at one time.  IMHO,
   this is wrong, it should be using SEMOPM (via seminfo.semopm).  The
   problem is that this value is needed to allocate a local buffer
   into which to copy the user's sem_ops.  Currently this is an auto
   variable:
        struct sembuf sops[MAX_SOPS];
   The simplest fix is to change this to:
        struct sembuf sops[seminfo.semopm];
   but this is a gcc extension.  The alternative is malloc() - either
   allocate/free the local buffer on each semop() call [which is slow]
   or allocate a single buffer and reuse it [which means more work for
   whoever puts fine-grained SMP locks into the semaphore handling].

2) TOG is unclear as to the type for sem_num in struct sembuf.  In
   semop(2) it's defined as `short', in sys/sem.h it's defined as
   `unsigned short'.  We (and DEC) currently use ushort (Linux and
   Solaris use short).  Which is the preferable type?

3) Neither FreeBSD nor TOG not clearly define semadj behaviour.  The
   wording is (roughly) sem_op is subtracted from semadj in semop()
   and semadj is added to semval in exit().  There does not appear to
   be a clear definition for behaviour when a process exits for the
   following cases:
a) semadj + semval > SEMVMX (maximum semaphore value).
   SEMAEM + SEMVMX < MAX_USHORT, so this may not be a problem
   (although I could write code that broke this).  I can't see any
   realistic scenario where this would be a problem.

b) semadj > semval
   TOG clearly defined semval as `unsigned short' [which breaks
   Terry's code], so semval can't go negative (which this implies).
   This could happen in the situation where a varying number of
   consumer processes exist and one dies, adjusting semval down.

   Since the problem occurs during exit() processing, it's not a
   simple problem of returning an error and letting the calling
   process resolve the problem.

Comments please.

Peter


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message