Date: Mon, 1 May 95 12:10:02 MDT From: terry@cs.weber.edu (Terry Lambert) To: didier@aida.remcomp.fr (Didier Derny) Cc: questions@FreeBSD.org Subject: Re: mmap / System V IPC Message-ID: <9505011810.AA14034@cs.weber.edu> In-Reply-To: <199505011436.QAA02154@aida.remcomp.fr> from "Didier Derny" at May 1, 95 04:36:15 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I have a server that need a shared memories with the acces controlled > by semaphores. > > How can I do that with mmap system calls. You can't. You can, however, use semaphore system calls. > It seems that the memory is no easily updated > > > for example I have two queues of small packets of 128 bytes > the server received the packet from a X25 line, enqueue the incoming packet > in the "in" queue, dequeue the "out" queue and transmit the data to > the X25 line. the user process does the same thing a the other end > of the queue. This mechanism is controlled by a set of semaphore. You have to use real semaphores to do this type of thing. > I know that this mechanism should be replaced by an AF_UNIX socket but > I do not have time to rewrite everything now. I don't see why a rewrite would be necessary. > Is there somewhere a detailed manual on the mmap system calls. The source. Sun systems have good man pages that should be applicable. The Usenix/O'Reilly 4.4 books should also work (or any BSD system man pages you can get your hands on). > Is the HAS_SEMAPHORE flag working with FreeBSD (I've not > been able to find it in the kernel). This flag doesn't do what you apparently think it does. This fag does not result in implied semaphoring between processes that might use the memory segment. Instead, what it does is notify the kernel that the memory may contain semaphores, and that special handling of accesses to the memory might need to be handled by the kernel. Since there is no kernel preemption possible, an atomic test-and-set or other two stage user space semaphore implementation does not need special protection by the kernel to prevent simultaneous access. Thus it's a noop. I expect that the SMP version will have to take this into account (as a matter of fact, I can see no way that this would not be automatically implied on an SMP system, although a kernel preemptive system might need some type of hint, so maybe it's only applicable to uniprocesser kernel multithreading when you think about it). What you need to do is use real semaphores, assert them prior to queue traversal, and deassert them once traversal is complete. This applies to queue insertion and deletion, and basically any operation that will result in pointer contents in shared memory being updated. These are pretty basic architecture requirements with regard to shared memory. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9505011810.AA14034>