From owner-freebsd-threads@FreeBSD.ORG Mon Jun 4 02:41:27 2012 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEAF11065673; Mon, 4 Jun 2012 02:41:27 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A342D8FC0C; Mon, 4 Jun 2012 02:41:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q542fRxG025537; Mon, 4 Jun 2012 02:41:27 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q542fRcg025529; Mon, 4 Jun 2012 02:41:27 GMT (envelope-from linimon) Date: Mon, 4 Jun 2012 02:41:27 GMT Message-Id: <201206040241.q542fRcg025529@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-threads@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: threads/168413: pthread_create memory leak in 9.0-i386? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 02:41:27 -0000 Synopsis: pthread_create memory leak in 9.0-i386? Responsible-Changed-From-To: freebsd-bugs->freebsd-threads Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 4 02:41:05 UTC 2012 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=168413 From owner-freebsd-threads@FreeBSD.ORG Mon Jun 4 11:07:51 2012 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F90F106566C for ; Mon, 4 Jun 2012 11:07:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7078FC1F for ; Mon, 4 Jun 2012 11:07:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q54B7pE1017608 for ; Mon, 4 Jun 2012 11:07:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q54B7oOv017606 for freebsd-threads@FreeBSD.org; Mon, 4 Jun 2012 11:07:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Jun 2012 11:07:50 GMT Message-Id: <201206041107.q54B7oOv017606@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 11:07:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/168417 threads pthread_getcpuclockid() does not work to specification o threa/168413 threads pthread_create memory leak in 9.0-i386? o threa/165173 threads [build] clang buildworld breaks libthr o threa/163512 threads libc defaults to single threaded o threa/160708 threads possible security problem with RLIMIT_VMEM o threa/150959 threads [libc] Stub pthread_once in libc should call _libc_onc o threa/148515 threads Memory / syslog strangeness in FreeBSD 8.x ( possible o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 o threa/128922 threads threads hang with xorg running o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/30464 threads [patch] pthread mutex attributes -- pshared 22 problems total. From owner-freebsd-threads@FreeBSD.ORG Tue Jun 5 12:15:26 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 47B23106564A for ; Tue, 5 Jun 2012 12:15:26 +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 9CBDC8FC16 for ; Tue, 5 Jun 2012 12:15:25 +0000 (UTC) Received: (surmail 22703 invoked from network); 5 Jun 2012 12:13:57 -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 ; 5 Jun 2012 12:13:57 -0000 Message-ID: <4FCDF845.9080704@inforcept.com> Date: Tue, 05 Jun 2012 15:15:01 +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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 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: Tue, 05 Jun 2012 12:15:26 -0000 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 From owner-freebsd-threads@FreeBSD.ORG Tue Jun 5 13:55:20 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 317EB1065673 for ; Tue, 5 Jun 2012 13:55:20 +0000 (UTC) (envelope-from s_sourceforge@nedprod.com) Received: from mail.nedproductions.biz (europe3.nedproductions.biz [91.121.122.107]) by mx1.freebsd.org (Postfix) with ESMTP id D6D748FC0C for ; Tue, 5 Jun 2012 13:55:19 +0000 (UTC) Received: by mail.nedproductions.biz (Postfix, from userid 999) id 2E6DA60096; Tue, 5 Jun 2012 14:33:29 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1338903209; bh=YpJfeFvY+nsUvpj0JA/uNi/0bXo6L4i275ycDh4oNik=; h=From:To:Date:Subject:In-reply-to:References; b=aQfI7EDAck5ykeN7plT9qZa7hrEv+YzbnG5S4uLUXdWrsUzTrZAc9zWcBI5A2/0mR FDDL8rq8OhzmQS/SE4KutJ5m3puR1SCQegQNasAsjl6saWN/nIm0R9UTDZLOS+Pgo7 YoVO/SAkPO09njdgthsVBiUDxxEH2V6YTnN2UYY8= X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.nedproductions.biz X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_DKIM_INVALID autolearn=ham version=3.3.2 Received: from [192.168.2.8] (dsl-076-041.cust.imagine.ie [87.232.76.41]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) (Authenticated sender: root@localhost) by mail.nedproductions.biz (Postfix) with ESMTPSA id A9FC360063 for ; Tue, 5 Jun 2012 14:33:27 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1338903208; bh=YpJfeFvY+nsUvpj0JA/uNi/0bXo6L4i275ycDh4oNik=; h=From:To:Date:Subject:In-reply-to:References; b=AEs1jPwAEXi2emq5LObaVZ1zUopKDW0miHfZunVsGtHwwtWYVLinfjXtQezoo3vhO gM75jbxzlKdYtJ55uGFvhDHGrC1CLUbiLmgcOL370ZHpDGYZYrdIC+mn8j//GFJfh6 z8pub1L/DTS9DuXnHHr6gEo/1PAcFiwXkWL/J1BQ= From: "Niall Douglas" To: freebsd-threads@freebsd.org Date: Tue, 05 Jun 2012 14:33:42 +0100 MIME-Version: 1.0 Message-ID: <4FCE0AB6.32705.5122593A@s_sourceforge.nedprod.com> Priority: normal In-reply-to: <4FCDF845.9080704@inforcept.com> References: <4FCDF845.9080704@inforcept.com> X-mailer: Pegasus Mail for Windows (4.63) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: Re: Inter Process Synchronisation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 13:55:20 -0000 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" -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/ From owner-freebsd-threads@FreeBSD.ORG Tue Jun 5 14:42:47 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 3CE96106566C for ; Tue, 5 Jun 2012 14:42:47 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1C4D38FC1C for ; Tue, 5 Jun 2012 14:42:47 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id C30B856205; Tue, 5 Jun 2012 09:42:46 -0500 (CDT) Date: Tue, 5 Jun 2012 09:42:46 -0500 From: Mark Linimon To: Resit Sahin Message-ID: <20120605144246.GC28802@lonesome.com> References: <4FCDF845.9080704@inforcept.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FCDF845.9080704@inforcept.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-threads@freebsd.org Subject: Re: Inter Process Synchronisation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 14:42:47 -0000 On Tue, Jun 05, 2012 at 03:15:01PM +0300, Resit Sahin wrote: > I am using NUMA architecture and ia64 CPUs like E5506. If you are talking about this: http://ark.intel.com/products/37096/Intel-Xeon-Processor-E5506-%284M-Cache-2_13-GHz-4_80-GTs-Intel-QPI%29 you have a processor that can run either what we call i386 or amd64. ia64 is something like this: http://ark.intel.com/products/43410/Intel-Itanium-Processor-9350-%2824M-Cache-1_73-GHz-4_80-GTs-Intel-QPI%29 mcl 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" > From owner-freebsd-threads@FreeBSD.ORG Wed Jun 6 15:00:30 2012 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 579961065673 for ; Wed, 6 Jun 2012 15:00:30 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2844C8FC17 for ; Wed, 6 Jun 2012 15:00:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q56F0TTl039529 for ; Wed, 6 Jun 2012 15:00:29 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q56F0TmP039528; Wed, 6 Jun 2012 15:00:29 GMT (envelope-from gnats) Date: Wed, 6 Jun 2012 15:00:29 GMT Message-Id: <201206061500.q56F0TmP039528@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Andrey Simonenko Cc: Subject: Re: threads/79683: svctcp_create() fails if multiple threads call at the same time, it's not thread-safe X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andrey Simonenko List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 15:00:30 -0000 The following reply was made to PR threads/79683; it has been noted by GNATS. From: Andrey Simonenko To: bug-followup@FreeBSD.org Cc: Subject: Re: threads/79683: svctcp_create() fails if multiple threads call at the same time, it's not thread-safe Date: Wed, 6 Jun 2012 17:54:13 +0300 According to the description in this PR (no test code was given) the solution from kern/165710 should correct that mistake. From owner-freebsd-threads@FreeBSD.ORG Wed Jun 6 21:16:07 2012 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2FFB1065677 for ; Wed, 6 Jun 2012 21:16:07 +0000 (UTC) (envelope-from s_sourceforge@nedprod.com) Received: from mail.nedproductions.biz (europe3.nedproductions.biz [91.121.122.107]) by mx1.freebsd.org (Postfix) with ESMTP id A36648FC1A for ; Wed, 6 Jun 2012 21:16:07 +0000 (UTC) Received: by mail.nedproductions.biz (Postfix, from userid 999) id 1C77F625E6; Wed, 6 Jun 2012 22:16:01 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1339017361; bh=wFuG2OiRU/U9P2H4Tro6d4nEWdJGCA3JepUKMmRIADg=; h=From:To:Date:Subject:In-reply-to:References; b=OSdCs08yndicBjxqHvYjwKmjyVjNNUxMxhe1cIHvf40oAicriORZQ9zOIkpolEzRg ArK/3MqLZTl7Zwic7b+Q1xtVvDfuNkEOmR6pGNuIi5pFVPah9jkGEY4+InSpkC96zV UI+OyMYH/D3lP/Rdc7NUiWTlT8WKbsKlBht8MPLc= X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.nedproductions.biz X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_DKIM_INVALID autolearn=ham version=3.3.2 Received: from [192.168.1.72] (host86-166-215-59.range86-166.btcentralplus.com [86.166.215.59]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) (Authenticated sender: root@localhost) by mail.nedproductions.biz (Postfix) with ESMTPSA id 1F8DD60078 for ; Wed, 6 Jun 2012 22:16:00 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1339017360; bh=wFuG2OiRU/U9P2H4Tro6d4nEWdJGCA3JepUKMmRIADg=; h=From:To:Date:Subject:In-reply-to:References; b=gwQIgRN8YjmXumq19sElMWf8z+TOQdEb5gucuy/sFHSw3nIWRO+oLsWd/IlpDHdGd QKQtBVb9wm7CKC2QXkDEqoxFQyLq+lbbzNrxIgGMpzIIbGBQCtybemo7ET3X/E/a3C W+xS7PlVI+1Y2TJuQNkLQ/X9366DQYkFXvI7gv14= From: "Niall Douglas" To: freebsd-threads@freebsd.org Date: Wed, 06 Jun 2012 22:16:00 +0100 MIME-Version: 1.0 Message-ID: <4FCFC890.598.57F02437@s_sourceforge.nedprod.com> Priority: normal In-reply-to: <4FCEFE33.9010708@inforcept.com> References: <4FCDF845.9080704@inforcept.com>, <4FCE0AB6.32705.5122593A@s_sourceforge.nedprod.com>, <4FCEFE33.9010708@inforcept.com> X-mailer: Pegasus Mail for Windows (4.63) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: Re: Inter Process Synchronisation X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 21:16:08 -0000 On 6 Jun 2012 at 9:52, Resit Sahin wrote: > I thought i can ask inter-process related issues in this list. Which > list is appropriate for such issues? This list is for FreeBSD specific threading issues. For example, if FreeBSD's POSIX threads implementation has some weird behaviour not seen on other POSIX implementations. It isn't for general POSIX programming questions. Yours is a general programming question, not even POSIX related really. There are many good books on threaded programming. > I did not get why should i need to create a new copy of the stats each > time? If what I said didn't make sense you then it's probably not important to your use case. If you want it to make sense, look up cache coherency overheads and bus snoop protocols. I vaguely remember once seeing an okay Wikipedia page on the topic. > 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? C11 and C++11 have a perfectly good atomics library. Failing that, GCC, Clang and MSVC all have their own atomics libraries which do what C11 and C++11 do but with different function names. Failing that, all modern assemblers have atomic instructions. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/