From owner-freebsd-hackers Wed Aug 16 5:22:48 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hda.hda.com (host65.hda.com [63.104.68.65]) by hub.freebsd.org (Postfix) with ESMTP id 40EC137BD59 for ; Wed, 16 Aug 2000 05:22:41 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.9.3/8.9.3) id IAA42181 for hackers@FreeBSD.ORG; Wed, 16 Aug 2000 08:23:55 -0400 (EDT) (envelope-from dufault) From: Peter Dufault Message-Id: <200008161223.IAA42181@hda.hda.com> Subject: Re: IPC, shared memory, syncronization AND threads... In-Reply-To: <200008152113.RAA39184@hda.hda.com> from Peter Dufault at "Aug 15, 2000 05:13:44 pm" To: hackers@FreeBSD.ORG Date: Wed, 16 Aug 2000 08:23:49 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've looked at the POSIX spec to find the right way to portably implement low overhead process synchronization. I think the right way is to add _POSIX_THREAD_PROCESS_SHARED support so that mutexes can be shared between processes. There is something vague about the spec. I don't see that you can reject "pthread_mutexattr_setpshared()" with EINVAL, and I don't clearly see that the mutexes in existence after a fork are defined to be a new set of mutexes with identical existing values. I have to assume they are as mutexes can be statically allocated and there is no way to ensure they are in a shared region without sharing pages happening to contain mutexes with that attribute of the new process space with the old one. Assuming unique mutexes after a fork unless they happen to be in a shared region, you could create a mutex in shared memory, apply pthread_mutexattr_setpshared() to it, and then have the usual pthread_mutex_lock()/pthread_mutex_unlock() interface support the high performance synchronization. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message