apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Jen <henry...@ztune.net>
Subject Re: [PATCH] PR 49709 apr_thread_pool race condition caused by use of separate mutexes?
Date Tue, 28 Sep 2010 03:30:30 GMT
2010/9/27 Jeff Trawick <trawick@gmail.com>:
> On Mon, Sep 27, 2010 at 4:55 PM, Henry Jen <henryjen@ztune.net> wrote:
>> 2010/9/27 Nick Kew <niq@apache.org>:
> (The next one is
> https://issues.apache.org/bugzilla/show_bug.cgi?id=48722, which has no
> patch.  Maybe I can debug it.)

I have a quick glance at it, and I would like to make a note that it
is not recommended to have tasks that can block a thread. Apparently
it can have dead lock if two blocking tasks blocks each other.

The origin design for the thread pool is to have a set of threads can
be used to execute a collections of tasks need to be done, each task
can be finished in a fair amount of time. In other words, the task
should not block the thread from execution for long and should never
have external dependencies on other tasks to avoid dead-lock. If a
task actually need some synchronization, it probably makes more sense
to have its own thread for doing it.

However, I think this particular test case should work if implement
correctly. I wonder if the fact waiting and flag is not marked
volatile cause any differences. I would like to test that, but on my
Mac, when trying to build apr trunk, I got following error. How can I
fix it? (Sorry that I haven't build apr for a long time...)

sunfish:apr henryjen$ ./configure
configure: error: cannot run /bin/sh build/config.sub


View raw message