[libdispatch-dev] libdispatch's thread model

Mario Schwalbe schwalbe at inf.tu-dresden.de
Fri Jan 29 09:49:58 PST 2010


On 28.01.2010 04:32, Mark Heily wrote:
> Mario Schwalbe wrote:
>> I know that Apple's non-posix extension to pthread isn't available.
>> Nevertheless, it should be possible to at least use a bounded number of
>> worker threads less than MAX_THREAD_COUNT (255). What about dynamically
>> setting MAX_THREAD_COUNT (or a similar variable) to the number of
>> processors
>> instead?
> A more useful solution would be to create a portable implementation of
> the Apple's pthread_workqueue interfaces [1]. This has been on my TODO
> list for some time, and I filed a Trac issue about this problem [2].

Ack. But since it most likely requires a kernel extension to implement
overcommitting, it cannot really be portable.

> I don't really want to reinvent the wheel, so my first attempt will use
> the APR thread pool routines [3]. To prevent deadlock, each workqueue
> will be serviced by a separate thread pool. This won't scale to large
> numbers of workqueues, and makes it impossible to implement priority
> levels, but it should be simple and work better than creating a new
> thread for each task.
> Stacy Son has kindly documented the pthread_workqueue(3) API which
> should be very helpful to get the correct semantics [4]. I have taken a
> stab at implementing the most important functions, and it looks
> promising [5].

And I played a bit and filled in some lines of code. (You didn't actually
compile or run it, did you?) The APR thread pool implementation is capable
of creating new threads. But only if a certain threshold of jobs waiting
is reached.

Also, in contrast to your suggestion, I used only one global thread pool,
since we cannot prevent deadlocks, but at least have priority support.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: thread-pool.c
Type: text/x-csrc
Size: 1343 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/libdispatch-dev/attachments/20100129/b6604beb/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: workqueue.c
Type: text/x-csrc
Size: 6704 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/libdispatch-dev/attachments/20100129/b6604beb/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: workqueue.h
Type: text/x-chdr
Size: 1961 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/libdispatch-dev/attachments/20100129/b6604beb/attachment-0002.bin>

More information about the libdispatch-dev mailing list