From owner-freebsd-current Tue Apr 7 15:01:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA00183 for freebsd-current-outgoing; Tue, 7 Apr 1998 15:01:39 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA29989 for ; Tue, 7 Apr 1998 15:01:08 -0700 (PDT) (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id WAA07018; Tue, 7 Apr 1998 22:00:08 GMT Date: Wed, 8 Apr 1998 07:00:07 +0900 (JST) From: Michael Hancock To: John-Mark Gurney cc: FreeBSD Current Subject: Re: kernel support for memory semaphores/locks... In-Reply-To: <19980407072623.51939@hydrogen.nike.efn.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 7 Apr 1998, John-Mark Gurney wrote: > I have writen a memory block based dynamic allocation system (mmalloc).. > I was planning on using a lock to prevent multiple processes from > accessing the allocation strutures... but the only real way is using > SYSV semaphores... and these are bad because it's silly to have all the overhead of a syscall to do locking. > 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... /usr/src/share/doc/papers/newvm.ascii.gz describes an interface that was never implemented, but worth reading. Regards, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message