[concurrency-interest] changing thread priority on the fly todeschedule zombie thread stuck in socketWrite0

Andy Nuss andrew_nuss at yahoo.com
Wed Jul 9 05:34:57 EDT 2014


Aside from my lack of knowledge on the mapping and scheduling of java threads to native threads on linux, I already know that a java thread on linux with lower priority before you start it, will starve relative to one with higher priority that is eating cpu, based on both expectation and testing.

For the purposes of this question, I was wondering what happens if on linux, a thread is stuck (looping without exit) in a native socketRead0 or socketWrite0 call (its happening to me and googling indicates its happened to others going back many years).  If from a monitoring thread I lower this "stuck" thread's priority, will it immediately start starving relative to the other functioning threads in the original pool of threads doing the socket calls?


On Wednesday, July 9, 2014 2:01 AM, David Holmes <davidcholmes at aapt.net.au> wrote:

thread priorities have almost no meaning under normal scheduling semantics. And 
on Linux (and elsewhere) changing Java Thread priority has no affect on the 
native thread priority, by default.
-----Original Message-----
>From: concurrency-interest-bounces at cs.oswego.edu  [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Andy  Nuss
>Sent: Wednesday, 9 July 2014 1:36 AM
>To: concurrency-interest at cs.oswego.edu
>Subject: [concurrency-interest]  changing thread priority on the fly todeschedule zombie thread stuck in  socketWrite0
>I'm  in the early stage of figuring out why my massive parallelization of S3 SDK  usage for storing blobs causes a small percent of my amazon blob puts to loop  forever in socketWrite0 without completing due to packet flow control problems  with amazon server in the native socket write (sometimes read as well).   Stopping in eclipse debugger and suspending and reactivating such a thread  proved to me it is looping in the native call, eating cpu and never  finishing.
>Though  I haven't figured out yet why I'm the only one with this problem with S3 and  java, I was wondering if given that interrupting the thread does not abort the  native call at all, perhaps I could set the thread to the minimum java thread  priority, effectively causing it to starve relative to all other threads in my  program, and of course I would replace that zombie thread in the pool.   Deploying on Linux.  Using JDK7.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20140709/afa1393b/attachment.html>

More information about the Concurrency-interest mailing list