From owner-freebsd-threads@FreeBSD.ORG Wed Jun 6 06:52:54 2012 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61F8F1065674 for ; Wed, 6 Jun 2012 06:52:54 +0000 (UTC) (envelope-from resit.sahin@inforcept.com) Received: from nusret.endersys.com (nusret.endersys.com [77.92.112.244]) by mx1.freebsd.org (Postfix) with ESMTP id 81A818FC17 for ; Wed, 6 Jun 2012 06:52:53 +0000 (UTC) Received: (surmail 19352 invoked from network); 6 Jun 2012 06:51:29 -0000 Received: from asy62.asy144.tellcom.com.tr (HELO AuthenticatedHELO) (resit.sahin@inforcept.com@[Authenticated]) (envelope-sender ) by nusret.endersys.com (surmail-1.0) with SMTP for ; 6 Jun 2012 06:51:29 -0000 Message-ID: <4FCEFE33.9010708@inforcept.com> Date: Wed, 06 Jun 2012 09:52:35 +0300 From: Resit Sahin Organization: Endersys-Inforcept User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-threads@freebsd.org References: <4FCDF845.9080704@inforcept.com> <4FCE0AB6.32705.5122593A@s_sourceforge.nedprod.com> In-Reply-To: <4FCE0AB6.32705.5122593A@s_sourceforge.nedprod.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Inter Process Synchronisation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: resit.sahin@inforcept.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 06:52:54 -0000 Hello, I thought i can ask inter-process related issues in this list. Which list is appropriate for such issues? I did not get why should i need to create a new copy of the stats each time? I have users and a counter for each user. This counter is incremented for each incoming network packet destined to this user. I consider to use a semaphore for the whole data structure. This means i have to lock the semaphore at least 100.000 times a second and all processes have to wait for that. Is it possible to use a semaphore so frequent? I would lock only the specific user if was able to use memory-based semaphores but i can use named semaphores only as we are using FreeBSD 8.2 at the moment. My structure: User1,counter=x User2,counter=y .......................... I wanted to post in this list because i want to learn if there are other ways to synchronise between processes without using semaphores. As far as i understand from your answer i can use atomic variables between multiple processes. Do you mean this with atomic operations? On 06/05/2012 04:33 PM, Niall Douglas wrote: > General programming questions aren't really an appropriate topic for > this list. However, if I were you, I'd have an atomic pointer which > points to the "current" version of the statistics. I'd then write a > new copy of the statistics each time there is a new copy, having an > atomic incremented usage count per copy, and set the "current" > version pointer atomically. When the atomic usage count goes to zero, > you retire that memory section for reuse if it is no longer current. > > The reason you should choose this design is because it's friendly on > cache coherency. You only have one cache line for the "current" > version pointer being bounced between all CPU cores rather than all > the cache lines which make up your statistics. > > Niall > > On 5 Jun 2012 at 15:15, Resit Sahin wrote: > >> Hello Everybody, >> >> >> I am working on a multi process system. I have 10 or more processes >> (that are created with fork) and i want to synchronise them. There is a >> data structure which must be shared among the processes. The data >> structure contains statistics about some users which are more then some >> thousands. Each process needs to "read from" / "write to" this data >> structure thousands of times in a second. They all may need to update it >> 500.000 times a second in total. This is the scenario i need to build. >> >> I am using NUMA architecture and ia64 CPUs like E5506. >> >> I have investigated the options i have in FreeBSD and come up with few >> solutions. I am already using sockets for inter-process communication >> but it does not seem to be suitable for the above scenario. It is very >> slow. >> >> The most suitable way seems to create a shared memory between the >> processes. The question is how to synchronise the access to the memory: >> >> I have found two solutions for synchronisation. One is mutexes and >> other is semaphores. >> >> The mutexes works only between threads but not between processes. Is >> there any support for inter process mutexes in FreeBSD 8.2 ? >> >> The second option is semaphores. There are two types of semaphores, they >> are named semaphores and the memory based semaphores. Memory based >> semaphores seem to be a better option but they do not support inter >> process operation in FreeBSD 8.2 . >> >> The only option seems to be using named semaphores and locking the whole >> data structure for each access. Would it be feasible to use named >> semaphores for locking 500.000 times a second? >> >> >> >> I have read about atomic operations here: >> http://www.freebsd.org/cgi/man.cgi?query=atomic_add&apropos=0&sektion=0&manpath=FreeBSD+9.0-RELEASE&arch=default&format=html >> >> >> Would atomic operations be an option in my case? >> >> The manual page says : >> >> "On the i386 architecture, the cache coherency >> model requires that the hardware perform this task, thus the atomic oper- >> ations are atomic across multiple processors. On the ia64 architecture, >> coherency is only guaranteed for pages that are configured to using a >> caching policy of either uncached or write back." >> >> >> Is it safe to use named semaphores for*ia64* architecture ? Does FreeBSD >> 8.2 support interprocess locking for ia64 architecture? >> >> >> >> Kind Regards >> Res,i S,ahin >> >> _______________________________________________ >> freebsd-threads@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-threads >> To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" >