Inter Process Synchronisation
resit.sahin at inforcept.com
Wed Jun 6 06:52:54 UTC 2012
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.
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.
> 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
>> 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:
>> 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 at freebsd.org mailing list
>> To unsubscribe, send any mail to "freebsd-threads-unsubscribe at freebsd.org"
More information about the freebsd-threads