From owner-freebsd-current Tue Apr 7 07:26:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA02146 for freebsd-current-outgoing; Tue, 7 Apr 1998 07:26:25 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from d182-89.uoregon.edu (d182-89.uoregon.edu [128.223.182.89]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA02140 for ; Tue, 7 Apr 1998 07:26:24 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by d182-89.uoregon.edu (8.8.7/8.8.7) id HAA11366; Tue, 7 Apr 1998 07:26:24 -0700 (PDT) Message-ID: <19980407072623.51939@hydrogen.nike.efn.org> Date: Tue, 7 Apr 1998 07:26:23 -0700 From: John-Mark Gurney To: FreeBSD Current Subject: kernel support for memory semaphores/locks... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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... 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... so, there are a couple ways we can do this... a) create a new type of file descriptor that is opened on a memory range... there are a couple of features with this... you could use the poll mechanism to obtain a lock on that region, or you could use read/write to this memory location... this could be useful for allowing another process to read/write into your data area... b) create two new sysctl's that do locking/unlocking on a region of memory... this is a simpler method but less powerful... using assembly to do atomic locking isn't an option as you would have to spin on the lock... or is there already a way to do locks using the kernel already? -- John-Mark Gurney Modem Rev/FAX: +1 541 346 9237 Cu Networking P.O. Box 5693, 97405 Live in Peace, destroy Micro$oft, support free software, run FreeBSD Don't trust anyone you don't have the source for To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message