From owner-freebsd-current Tue Apr 7 14:22:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA19080 for freebsd-current-outgoing; Tue, 7 Apr 1998 14:22:52 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA18691 for ; Tue, 7 Apr 1998 14:20:38 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.5) with ESMTP id SAA02167; Tue, 7 Apr 1998 18:44:36 +0200 (CEST) To: John-Mark Gurney cc: FreeBSD Current Subject: Re: kernel support for memory semaphores/locks... In-reply-to: Your message of "Tue, 07 Apr 1998 07:26:23 PDT." <19980407072623.51939@hydrogen.nike.efn.org> Date: Tue, 07 Apr 1998 18:44:35 +0200 Message-ID: <2165.891967475@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >so, how do we go about locking on a shared memory areas? > >after discussing this with a friend, ther HAS to be a lock based on a >shared memory location... the problem with storing the SYSV semaphore >semid is that there isn't an atomic way of obtaining the new semid >and putting it in a shared location after a machine reboot... Make your own lock with the cmp8xchg instruction, just like the kernel does. Check the "lock" instruction on the i386. Also check out the "mplock.[schwhatever]" somewhere in the kernel. >using assembly to do atomic locking isn't an option as you would have >to spin on the lock... No, you'd go to sleep for a jiffy and check again... I belive a yield() syscall is in the pipeline or maybe already in. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "Drink MONO-tonic, it goes down but it will NEVER come back up!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message