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 05:31:09 GMT
OK, I tried this on my OpenSolaris box, and believe I figured out what
is going on.

The dead-lock happens when the initial one worker thread get into idle
first as no tasks are pushed yet, then two push comes in. Under this
circumstance, there is one thread idle, thus no new thread will be
created.

Now the idle thread get to pick up the first task, but is blocked,
thus no other thread will pick up the second task, which caused the
dead-lock.

As explained, this scenario is not supported by design as we expect
the task should not be blocking. Understood the cooperative approach
is not optimal, but that is all we needed at that moment and simplify
things a lot.

Cheers,
Henry

2010/9/27 Henry Jen <henryjen@ztune.net>:
> 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
>
> Cheers,
> Henry
>

Mime
View raw message