From marcus at freebsd.org Thu Oct 1 16:17:29 2009 From: marcus at freebsd.org (Joe Marcus Clarke) Date: Thu Oct 1 16:17:35 2009 Subject: [Fwd: Pthread fix to libc on FreeBSD 9.X, 8.X, 7.X, and 6.X] Message-ID: <4AC4D099.3000109@freebsd.org> Kostik already gave his blessing, but before I commit this, I figured I'd run this by you guys. Is this patch okay? Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -------------- next part -------------- An embedded message was scrubbed... From: Joe Marcus Clarke Subject: Pthread fix to libc on FreeBSD 9.X, 8.X, 7.X, and 6.X Date: Thu, 01 Oct 2009 00:05:28 -0400 Size: 3938 Url: http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20091001/5cf60905/PthreadfixtolibconFreeBSD9.X8.X7.Xand6.X.eml From deischen at freebsd.org Thu Oct 1 16:40:37 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Thu Oct 1 16:40:43 2009 Subject: [Fwd: Pthread fix to libc on FreeBSD 9.X, 8.X, 7.X, and 6.X] In-Reply-To: <4AC4D099.3000109@freebsd.org> References: <4AC4D099.3000109@freebsd.org> Message-ID: On Thu, 1 Oct 2009, Joe Marcus Clarke wrote: > Kostik already gave his blessing, but before I commit this, I figured > I'd run this by you guys. Is this patch okay? Looks okay to me. -- DE From bugmaster at FreeBSD.org Mon Oct 5 11:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 5 11:09:45 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200910051107.n95B719X088819@freefall.freebsd.org> 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/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 p threa/135462 threads [PATCH] _thread_cleanupspecific() doesn't handle delet o threa/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c 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/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat 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. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe 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/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 41 problems total. From jilles at stack.nl Mon Oct 5 17:17:31 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Mon Oct 5 17:17:38 2009 Subject: review request: making openat(2) a cancellation point Message-ID: <20091005171729.GA2830@stack.nl> While implementing a faster, cleaner and more compliant getcwd(3) using *at functions, I noticed that openat() was not a cancellation point (unlike open()). I think that should be fixed first, both for its own sake and because getcwd() will need to use _openat. I created the attached patch. It seems to work, I can still compile and run non-threaded and threaded programs using openat() and I can cancel a thread blocked in openat() (such as trying to open a fifo). I can also use _openat in libc. However, I think some review is appropriate because it all looks fairly complicated. Because libkse and libc_r don't seem to be built, I have not updated them. Note that this will cause threaded 9.x binaries that use openat() to break on 8.x. This is to be expected. -- Jilles Tjoelker -------------- next part -------------- A non-text attachment was scrubbed... Name: openat-cancel.patch Type: text/x-diff Size: 3262 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20091005/7f6eed23/openat-cancel.bin From deischen at freebsd.org Mon Oct 5 18:27:18 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Mon Oct 5 18:27:25 2009 Subject: review request: making openat(2) a cancellation point In-Reply-To: <20091005171729.GA2830@stack.nl> References: <20091005171729.GA2830@stack.nl> Message-ID: On Mon, 5 Oct 2009, Jilles Tjoelker wrote: > While implementing a faster, cleaner and more compliant getcwd(3) using > *at functions, I noticed that openat() was not a cancellation point > (unlike open()). I think that should be fixed first, both for its own > sake and because getcwd() will need to use _openat. POSIX states that openat() is a cancellation point, so it should be changed accordingly. I have not reviewed th patch, but the intent is valid :-) > I created the attached patch. It seems to work, I can still compile and > run non-threaded and threaded programs using openat() and I can cancel a > thread blocked in openat() (such as trying to open a fifo). I can also > use _openat in libc. However, I think some review is appropriate because > it all looks fairly complicated. > > Because libkse and libc_r don't seem to be built, I have not updated > them. > > Note that this will cause threaded 9.x binaries that use openat() to > break on 8.x. This is to be expected. -- DE From jhb at freebsd.org Fri Oct 9 16:08:14 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Oct 9 16:08:56 2009 Subject: review request: making openat(2) a cancellation point In-Reply-To: <20091005171729.GA2830@stack.nl> References: <20091005171729.GA2830@stack.nl> Message-ID: <200910091038.34735.jhb@freebsd.org> On Monday 05 October 2009 1:17:29 pm Jilles Tjoelker wrote: > While implementing a faster, cleaner and more compliant getcwd(3) using > *at functions, I noticed that openat() was not a cancellation point > (unlike open()). I think that should be fixed first, both for its own > sake and because getcwd() will need to use _openat. > > I created the attached patch. It seems to work, I can still compile and > run non-threaded and threaded programs using openat() and I can cancel a > thread blocked in openat() (such as trying to open a fifo). I can also > use _openat in libc. However, I think some review is appropriate because > it all looks fairly complicated. > > Because libkse and libc_r don't seem to be built, I have not updated > them. > > Note that this will cause threaded 9.x binaries that use openat() to > break on 8.x. This is to be expected. From what I can tell the patch looks fine to me. -- John Baldwin From deischen at freebsd.org Sun Oct 11 00:03:59 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Sun Oct 11 00:04:37 2009 Subject: thread scheduling at mutex unlock In-Reply-To: <482BF5EA.5010806@icyb.net.ua> References: <482B0297.2050300@icyb.net.ua> <482BBA77.8000704@freebsd.org> <482BF5EA.5010806@icyb.net.ua> Message-ID: On Thu, 15 May 2008, Andriy Gapon wrote: > Or even more realistic: there should be a feeder thread that puts things on > the queue, it would never be able to enqueue new items until the queue > becomes empty if worker thread's code looks like the following: > > while(1) > { > pthread_mutex_lock(&work_mutex); > while(queue.is_empty()) > pthread_cond_wait(...); > //dequeue item > ... > pthread_mutex_unlock(&work mutex); > //perform some short and non-blocking processing of the item > ... > } > > Because the worker thread (while the queue is not empty) would never enter > cond_wait and would always re-lock the mutex shortly after unlocking it. Well in theory, the kernel scheduler will let both threads run fairly with regards to their cpu usage, so this should even out the enqueueing and dequeueing threads. You could also optimize the above a little bit by dequeueing everything in the queue instead of one at a time. > So while improving performance on small scale this mutex re-acquire-ing > unfairness may be hurting interactivity and thread concurrency and thus > performance in general. E.g. in the above example queue would always be > effectively of depth 1. > Something about "lock starvation" comes to mind. > > So, yes, this is not about standards, this is about reasonable expectations > about thread concurrency behavior in a particular implementation (libthr). > I see now that performance advantage of libthr over libkse came with a price. > I think that something like queued locks is needed. They would clearly reduce > raw throughput performance, so maybe that should be a new (non-portable?) > mutex attribute. -- DE _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From bugmaster at FreeBSD.org Mon Oct 12 11:07:03 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 12 11:09:34 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200910121107.n9CB72Il036572@freefall.freebsd.org> 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/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 p threa/135462 threads [PATCH] _thread_cleanupspecific() doesn't handle delet o threa/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c 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/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat 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. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe 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/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 41 problems total. From bugmaster at FreeBSD.org Mon Oct 19 11:07:03 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 19 11:09:46 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200910191107.n9JB72De063588@freefall.freebsd.org> 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/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 p threa/135462 threads [PATCH] _thread_cleanupspecific() doesn't handle delet o threa/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c 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/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat 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. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe 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/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 41 problems total. From bugmaster at FreeBSD.org Mon Oct 26 11:07:09 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 26 11:10:26 2009 Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org Message-ID: <200910261107.n9QB788J043905@freefall.freebsd.org> 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/136345 threads Recursive read rwlocks in thread A cause deadlock with o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 p threa/135462 threads [PATCH] _thread_cleanupspecific() doesn't handle delet o threa/133734 threads 32 bit libthr failing pthread_create() o threa/128922 threads threads hang with xorg running o threa/127225 threads bug in lib/libthr/thread/thr_init.c 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/118715 threads kse problem o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/116181 threads /dev/io-related io access permissions are not propagat 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. s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/83914 threads [libc] popen() doesn't work in static threaded program o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/80435 threads panic on high loads o threa/79887 threads [patch] freopen() isn't thread-safe 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/76690 threads fork hang in child for -lc_r o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/70975 threads [sysvipc] unexpected and unreliable behaviour when usi s threa/69020 threads pthreads library leaks _gc_mutex s threa/49087 threads Signals lost in programs linked with libc_r s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/34536 threads accept() blocks other threads s threa/32295 threads [libc_r] [patch] pthread(3) dont dequeue signals s threa/30464 threads pthread mutex attributes -- pshared s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o 41 problems total.