Date: Wed, 17 Feb 1999 12:26:51 +1100 From: Peter Jeremy <peter.jeremy@AUSS2.ALCATEL.COM.AU> To: hackers@FreeBSD.ORG Subject: Semaphore handling Message-ID: <99Feb17.121602est.40408@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Feb17.121602est.40408>