From owner-freebsd-threads@FreeBSD.ORG Mon Feb 3 11:06:55 2014 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C20421DC for ; Mon, 3 Feb 2014 11:06:55 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 94FF91A61 for ; Mon, 3 Feb 2014 11:06:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s13B6tV3022804 for ; Mon, 3 Feb 2014 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s13B6tYe022802 for freebsd-threads@FreeBSD.org; Mon, 3 Feb 2014 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Feb 2014 11:06:55 GMT Message-Id: <201402031106.s13B6tYe022802@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 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 11:06:55 -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/186309 threads [patch] pthread_kill() broken code - signal to current o threa/184073 threads wrong signal delivery to multithreaded processes in Pe o threa/180652 threads [patch] compat32 problem in clock_getcpuclockid2 o threa/180496 threads clock_gettime() does not return CPU-time for zombie pr o threa/168417 threads pthread_getcpuclockid() does not work to specification 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/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash 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/30464 threads [patch] pthread mutex attributes -- pshared 21 problems total. From owner-freebsd-threads@FreeBSD.ORG Thu Feb 6 01:26:44 2014 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2F5A7E8 for ; Thu, 6 Feb 2014 01:26:44 +0000 (UTC) Received: from mout.web.de (mout.web.de [212.227.15.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E314112E for ; Thu, 6 Feb 2014 01:26:44 +0000 (UTC) Received: from nil ([85.214.255.69]) by smtp.web.de (mrweb102) with ESMTPA (Nemesis) id 0MJkxE-1WCK7R40H6-001BBj for ; Thu, 06 Feb 2014 02:21:31 +0100 From: Luca Bayer To: John Baldwin Subject: Re: What is the status of thread process-shared synchronization? In-Reply-To: <201009231006.40019.jhb@freebsd.org> (John Baldwin's message of "Thu, 23 Sep 2010 10:06:39 -0400") Date: Thu, 06 Feb 2014 01:47:10 +0100 Message-ID: <20140206.86sirxgj8x@web.de> References: <201009231006.40019.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K0:JvGbUUl/7TkVwemsI24RE1aqBl7Tn+66T2sTsMjTm7TAMWjN+MW f3EB1vtjUWNKXMAzE887L6JVNoW1GWAIjF5Z7Ip+TMSp2SZdK00pL+rS32bZu4rj4CQ27jE UGLfvKx+NvJ/Vm+FkeJKhmtn9NLHB/KR4hBEDxGArHNXUXG4xgFpIBR7/UFzFgO3KB4F+wT KKeQcwjWnAz8f0LS13Ynw== Cc: Alexander Churanov , David Xu , freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 01:26:44 -0000 John Baldwin writes: >> Hi folks! >> >> The FreeBSD 8.1 manual pages state that pthread process-shared >> synchronization option is not supported, at least for some primitives. >> >> 1) Are there any plans to implement this option? >> 2) Is anybody working on that? >> 3) What are the main obstacles which prevent us from having the option >> implemented? >> >> I am teaching students UNIX-like systems in general and FreeBSD in >> particular. I've set them a task on synchronizing processes reading >> and writing from a shared-memory cache. But then found that in spite >> of PTHREAD_PROCESS_SHARED being available, it is not supported. I've >> endeavored to fix POSIX rwlocks by making pthread_rwlock_t a >> structure, but then found that POSIX semaphores do not support >> process-shared attribute either. > > I believe POSIX semaphores in 9 do now support PTHREAD_PROCESS_SHARED. David > Xu implemented it. He may be able to MFC this to 8-stable. I wonder what's the status of process-shared mutexes. They still don't work as compared to glibc (linux and kfreebsd). Here's a failing example http://www.andy-pearce.com/wiki/notes/sharing_pthreads_primitives_between_processes $ ./test ... About to fork. [0] PARENT: sleeping for 1 second. [0] CHILD: acquiring mutex. [0] CHILD: sleeping for 2 seconds. [1] PARENT: acquiring mutex [1] PARENT: waking child. [1] PARENT: waiting for child. [2] CHILD: waiting to be woken. load: 3.71 cmd: test 47522 [uwait] 17.86r 0.00u 0.00s 0% 2084k ^C where pthread_mutexattr_setpshared() actually returns EINVAL with PTHREAD_PROCESS_SHARED. It's also not possible to delay loading -lpthread due to missing pthread stubs in libc. > >> 4) Do we have any synchronization primitive capable of synchronizing >> threads in different processes in FreeBSD? > > Unfortunately the various POSIX/SYSV primitives do not currently support it in > 8. You could implement a shared mutex on top of umtx fairly easily I believe. > umtx itself is address-space agnostic (so a umtx object can be shared among > processes), and the existing pthread_mutex code can probably be borrowed > directly to implement a mutex. I think the biggest obstacle for FreeBSD is > changing the definition of pthread_mutex_t, etc. to be structures instead of > pointers to dynamically allocated structures. From owner-freebsd-threads@FreeBSD.ORG Thu Feb 6 05:41:17 2014 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6944EB6; Thu, 6 Feb 2014 05:41:17 +0000 (UTC) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F2901775; Thu, 6 Feb 2014 05:41:16 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.7/8.14.7/NETPLEX) with ESMTP id s165dDsU000937; Thu, 6 Feb 2014 00:39:13 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Thu, 06 Feb 2014 00:39:13 -0500 (EST) Date: Thu, 6 Feb 2014 00:39:13 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Luca Bayer Subject: Re: What is the status of thread process-shared synchronization? In-Reply-To: <20140206.86sirxgj8x@web.de> Message-ID: References: <201009231006.40019.jhb@freebsd.org> <20140206.86sirxgj8x@web.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Churanov , David Xu , freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 05:41:17 -0000 On Thu, 6 Feb 2014, Luca Bayer wrote: > John Baldwin writes: > >>> Hi folks! >>> >>> The FreeBSD 8.1 manual pages state that pthread process-shared >>> synchronization option is not supported, at least for some primitives. >>> >>> 1) Are there any plans to implement this option? >>> 2) Is anybody working on that? >>> 3) What are the main obstacles which prevent us from having the option >>> implemented? >>> >>> I am teaching students UNIX-like systems in general and FreeBSD in >>> particular. I've set them a task on synchronizing processes reading >>> and writing from a shared-memory cache. But then found that in spite >>> of PTHREAD_PROCESS_SHARED being available, it is not supported. I've >>> endeavored to fix POSIX rwlocks by making pthread_rwlock_t a >>> structure, but then found that POSIX semaphores do not support >>> process-shared attribute either. >> >> I believe POSIX semaphores in 9 do now support PTHREAD_PROCESS_SHARED. David >> Xu implemented it. He may be able to MFC this to 8-stable. > > I wonder what's the status of process-shared mutexes. They still don't > work as compared to glibc (linux and kfreebsd). Here's a failing example [ ... ] Process shared synchronization objects are not yet supported because our POSIX synchronization object types are pointers and are allocated by the process - they can't be shared. >> Unfortunately the various POSIX/SYSV primitives do not currently support it in >> 8. You could implement a shared mutex on top of umtx fairly easily I believe. >> umtx itself is address-space agnostic (so a umtx object can be shared among >> processes), and the existing pthread_mutex code can probably be borrowed >> directly to implement a mutex. I think the biggest obstacle for FreeBSD is >> changing the definition of pthread_mutex_t, etc. to be structures instead of >> pointers to dynamically allocated structures. Yes, there are some ABI problems to be worked out if we change our synchronization objects (at least mutex and CVs) to structs. David has some code that does this, but we're not quite sure how to treat the ABI compatibility. One problem is if an older compiled library (which views and creates mutexes/CVs as pointers) passes a mutex/CV to a newer compiled library or application that views the mutex/CV as a struct. We think we can solve this by or'ing a 1 into the pointer returned from the compat version of the foo_create() function. Then we can tell if the object is a pointer or not - ugly, but it might work. The other option is to bump library versions - this is messy too, but we've done it before. The other problem is that some code (looks like the NVIDIA driver) doesn't link to libpthread and uses dlsym() to get the address of pthread_mutex_create(). (to see if the calling application needs threading support). If not null, it then calls pthread_mutex_create() by dereferencing the address. This could return the the pthread_mutex_create() that uses structs, but the NVIDIA driver, if not rebuilt, would only allocate a pointer for it. I argue using dlsym() and friends bypass any ABI compatibility and shouldn't really be supported. I don't think bumping library versions would even solve this problem. -- DE From owner-freebsd-threads@FreeBSD.ORG Sat Feb 8 16:00:01 2014 Return-Path: Delivered-To: freebsd-threads@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 625C3F69 for ; Sat, 8 Feb 2014 16:00:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 352EE16C5 for ; Sat, 8 Feb 2014 16:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s18G01KY017342 for ; Sat, 8 Feb 2014 16:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s18G00OC017341; Sat, 8 Feb 2014 16:00:00 GMT (envelope-from gnats) Date: Sat, 8 Feb 2014 16:00:00 GMT Message-Id: <201402081600.s18G00OC017341@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: threads/186309: commit references a PR X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dfilter service List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 16:00:01 -0000 The following reply was made to PR threads/186309; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: threads/186309: commit references a PR Date: Sat, 8 Feb 2014 15:51:54 +0000 (UTC) Author: kib Date: Sat Feb 8 15:51:42 2014 New Revision: 261637 URL: http://svnweb.freebsd.org/changeset/base/261637 Log: MFC r261354: In _pthread_kill(), if passed pthread is current thread, do not send the signal second time, by adding the missed else before if statement. PR: threads/186309 Modified: stable/9/lib/libthr/thread/thr_kill.c Directory Properties: stable/9/lib/libthr/ (props changed) Modified: stable/9/lib/libthr/thread/thr_kill.c ============================================================================== --- stable/9/lib/libthr/thread/thr_kill.c Sat Feb 8 15:51:24 2014 (r261636) +++ stable/9/lib/libthr/thread/thr_kill.c Sat Feb 8 15:51:42 2014 (r261637) @@ -42,24 +42,27 @@ __weak_reference(_pthread_kill, pthread_ int _pthread_kill(pthread_t pthread, int sig) { - struct pthread *curthread = _get_curthread(); + struct pthread *curthread; int ret; /* Check for invalid signal numbers: */ if (sig < 0 || sig > _SIG_MAXSIG) /* Invalid signal: */ - ret = EINVAL; + return (EINVAL); + + curthread = _get_curthread(); + /* * Ensure the thread is in the list of active threads, and the * signal is valid (signal 0 specifies error checking only) and * not being ignored: */ - else if (curthread == pthread) { + if (curthread == pthread) { if (sig > 0) _thr_send_sig(pthread, sig); ret = 0; - } if ((ret = _thr_find_thread(curthread, pthread, /*include dead*/0)) - == 0) { + } else if ((ret = _thr_find_thread(curthread, pthread, + /*include dead*/0)) == 0) { if (sig > 0) _thr_send_sig(pthread, sig); THR_THREAD_UNLOCK(curthread, pthread); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-threads@FreeBSD.ORG Sat Feb 8 16:00:02 2014 Return-Path: Delivered-To: freebsd-threads@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 66AB6F6C for ; Sat, 8 Feb 2014 16:00:02 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 38EE816C7 for ; Sat, 8 Feb 2014 16:00:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s18G0289017348 for ; Sat, 8 Feb 2014 16:00:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s18G029B017347; Sat, 8 Feb 2014 16:00:02 GMT (envelope-from gnats) Date: Sat, 8 Feb 2014 16:00:02 GMT Message-Id: <201402081600.s18G029B017347@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: threads/186309: commit references a PR X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dfilter service List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 16:00:02 -0000 The following reply was made to PR threads/186309; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: threads/186309: commit references a PR Date: Sat, 8 Feb 2014 15:51:31 +0000 (UTC) Author: kib Date: Sat Feb 8 15:51:24 2014 New Revision: 261636 URL: http://svnweb.freebsd.org/changeset/base/261636 Log: MFC r261354: In _pthread_kill(), if passed pthread is current thread, do not send the signal second time, by adding the missed else before if statement. PR: threads/186309 Modified: stable/10/lib/libthr/thread/thr_kill.c Directory Properties: stable/10/ (props changed) Modified: stable/10/lib/libthr/thread/thr_kill.c ============================================================================== --- stable/10/lib/libthr/thread/thr_kill.c Sat Feb 8 13:51:15 2014 (r261635) +++ stable/10/lib/libthr/thread/thr_kill.c Sat Feb 8 15:51:24 2014 (r261636) @@ -42,24 +42,27 @@ __weak_reference(_pthread_kill, pthread_ int _pthread_kill(pthread_t pthread, int sig) { - struct pthread *curthread = _get_curthread(); + struct pthread *curthread; int ret; /* Check for invalid signal numbers: */ if (sig < 0 || sig > _SIG_MAXSIG) /* Invalid signal: */ - ret = EINVAL; + return (EINVAL); + + curthread = _get_curthread(); + /* * Ensure the thread is in the list of active threads, and the * signal is valid (signal 0 specifies error checking only) and * not being ignored: */ - else if (curthread == pthread) { + if (curthread == pthread) { if (sig > 0) _thr_send_sig(pthread, sig); ret = 0; - } if ((ret = _thr_find_thread(curthread, pthread, /*include dead*/0)) - == 0) { + } else if ((ret = _thr_find_thread(curthread, pthread, + /*include dead*/0)) == 0) { if (sig > 0) _thr_send_sig(pthread, sig); THR_THREAD_UNLOCK(curthread, pthread); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"