I have written a pure userspace implementation of the Darwin pthread_workqueue API as used by libdispatch. This is based on Stacey Son's port to FreeBSD [1], but does not include any of the kernel bits. It's portable to a wide range of POSIX-compliant platforms. I have tested it under Linux, and it shows major improvements in the performance and stability of the libdispatch test suite. I havn't implemented overcommit or multiple priority levels yet, but the basic workqueue functionality is there. I have a few ideas for adding kernel support and will be developing a Linux kernel module to complement the existing userspace code. A tarball of the source code is here: http://mark.heily.com/src/libpthread_workqueue-0.1.tar.gz The SVN repository is available here: svn://mark.heily.com/libpthread_workqueue To try this with libdispatch, add '-lpthread_workqueue' to the LDADD variable in testing/Makefile.am. Regards, - Mark [1] http://people.freebsd.org/~sson/thrworkq/
This is excellent! On Mon, Jun 14, 2010 at 9:36 PM, Mark Heily <mark@heily.com> wrote:
I have written a pure userspace implementation of the Darwin pthread_workqueue API as used by libdispatch. This is based on Stacey Son's port to FreeBSD [1], but does not include any of the kernel bits. It's portable to a wide range of POSIX-compliant platforms. I have tested it under Linux, and it shows major improvements in the performance and stability of the libdispatch test suite.
I havn't implemented overcommit or multiple priority levels yet, but the basic workqueue functionality is there. I have a few ideas for adding kernel support and will be developing a Linux kernel module to complement the existing userspace code.
A tarball of the source code is here:
http://mark.heily.com/src/libpthread_workqueue-0.1.tar.gz
The SVN repository is available here:
svn://mark.heily.com/libpthread_workqueue
To try this with libdispatch, add '-lpthread_workqueue' to the LDADD variable in testing/Makefile.am.
Regards,
- Mark
[1] http://people.freebsd.org/~sson/thrworkq/ _______________________________________________ libdispatch-dev mailing list libdispatch-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev
Hi Mark, That's very interesting, and certainly solves the portability problem for those OSes unwilling / unable to implement pthread workqueues in kernel space. How are you planning on implementing the system-wide load balancing behavior? A global semaphore of some sort, I would assume, but it's really your assumptions I think we're interested in. :) Looking further forward, is this something you would like to propose as part of the "official libdispatch sources" for making the code base more portable? Thanks, - Jordan On Jun 14, 2010, at 9:36 PM, Mark Heily wrote:
I have written a pure userspace implementation of the Darwin pthread_workqueue API as used by libdispatch. This is based on Stacey Son's port to FreeBSD [1], but does not include any of the kernel bits. It's portable to a wide range of POSIX-compliant platforms. I have tested it under Linux, and it shows major improvements in the performance and stability of the libdispatch test suite.
I havn't implemented overcommit or multiple priority levels yet, but the basic workqueue functionality is there. I have a few ideas for adding kernel support and will be developing a Linux kernel module to complement the existing userspace code.
A tarball of the source code is here:
http://mark.heily.com/src/libpthread_workqueue-0.1.tar.gz
The SVN repository is available here:
svn://mark.heily.com/libpthread_workqueue
To try this with libdispatch, add '-lpthread_workqueue' to the LDADD variable in testing/Makefile.am.
Regards,
- Mark
[1] http://people.freebsd.org/~sson/thrworkq/ _______________________________________________ libdispatch-dev mailing list libdispatch-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/libdispatch-dev
On 06/20/2010 04:16 PM, Jordan K. Hubbard wrote:
How are you planning on implementing the system-wide load balancing behavior? A global semaphore of some sort, I would assume, but it's really your assumptions I think we're interested in. :)
There are a couple of big problems with using a global semaphore. A global semaphore would need to be world-writable, which leads to a trivial denial-of-service vulnerability. Another problem is that a thread may take the semaphore, and then sleep or block while waiting for I/O. This would starve other threads that are waiting for the semaphore to be released. Instead of using IPC, I'm planning to manage the size of the thread pool by using a combination of four variables: a := the total number of pending work items on all queues b := the number of worker threads c := the 1-minute load average from getloadavg(3) d := the number of online CPUs These four variables will be used to compute two ratios: items_per_worker := a / b per_cpu_runqueue_length := c / d If the workload is high (items_per_worker > 1) and system load is low (per_cpu_runqueue_length <= 1) , additional worker threads will be added to the pool. Conversely, if the system load is high (per_cpu_runqueue_length > 1) or there are lots of idle workers (items_per_worker < 0.5), some of the worker threads will be removed from the pool.
Looking further forward, is this something you would like to propose as part of the "official libdispatch sources" for making the code base more portable?
I think it makes sense to import this into the libdispatch source tree instead of distributing it as a separate library. Once some of the missing pieces are finished, I'll submit a patch to integrate it with libdispatch. Regards, - Mark
participants (3)
-
David Leimbach
-
Jordan K. Hubbard
-
Mark Heily