http://blog.gmane.org/gmane.comp.java.jsr.166-concurrency hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9518 <pre> Hi all, I suppose the issue might have popped multiple times, yet I have not seen it anywhere. Stacks are great for object pools but the only available in JDK are either: based on Vector or not thread safe (ArrayDeque), or don't have good size() method (ConcurrentLinkedDeque). JSR codebase has a dead ConcurrentStack on its own with slow size() method. Some projects like tomcat use CLQ for object pools, combined w/ an AtomicInteger for fast size() method. Neither queue make for proper pools, nor unsynchronized size() is a nice option. A few years back I thought that stacks can easily incorporate size on the top of the head by keeping it along w/ the data element, thus having O(1) sync. size w/o any extra hurdle. Below is the code I've come up and it has been in production since. It makes a great pool for direct ByteBuffers and some other memory heavy structures. With proper sizing the hit ratio is usually over 99%. http://pastebin.com/GW1afBpz The Code at pastebin If you can share any possible problem</pre> bestsss 2012-05-26T21:42:34 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9515 <pre>We have a multithreaded application which relies heavily on the F/J framework. When threadprofiling the application we've observed that not all F/J threads are kept busy. Some threads spend a lot of time waiting, thus making suboptimal use of the available CPUs in the system. I've discovered it may have something to do with the workload distribution. The tasks are being spawned according to a quad-tree structure. When each branch in the quad tree has roughly the same amount of work to do, all F/J threads are nicely occupied (uniform workload). When some branches however have a lot more work to do, while others don't, some F/J threads are waiting (non-uniform workload). I am guessing it has something to do with a suboptimality in work stealing: in the case of uniform workload, there is little to no work stealing going on, and everything behaves nicely. In the case of non-uniform workload, there is (a lot?) more work stealing going on, which somehow results in waiting F/J threads. I have attache</pre> Peter De Maeyer 2012-05-26T08:55:54 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9506 <pre>I have a method that needs to be synchronized based on a key passed as parameter, that is, for same key multiple threads shouldn't be running. Following is what I did-- static final ConcurrentMap&lt;String,Boolean&gt; IN_PROGRESS = new ConcurrentHashMap&lt;String,Boolean&gt;(); void foo(String key){ if(null == IN_PROGRESS.putIfAbsent(key, Boolean.TRUE)){ // no other thread is processing this key try{ // process this key } finally { // done with processing this key IN_PROGRESS.remove(key) } } else { // some other thread is running this key, discard it } } this works if I need to discard the request to process the key from thread t1 when another thread, t2, is processing that key. I need help to do following- make thread t1 wait while t2 is processing the key and resume t1 when t2 is finish processing same key. I'm aware that if there are multiple threads t1,t3,t4.. etc waiting for t2 to finish anyone of these thread can wake up and start proce</pre> bhm 2012-05-24T14:22:37 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9501 <pre>Hi Doug and all, Using the latest version of the ForkJoinPool available on the jsr166y website, we ran into an issue/regression with our existing code base. In our code, we have a single task that scans a fairly large fact table while applying some filtering conditions. Any row that passes this condition must then be processed. The pattern that we use is that the scanning task saves (in an array) the rows that passed the condition and forks a processing task as soon as we have enough rows to process (say 1024). We expect that these processing tasks will be picked up (i.e. stolen) by the other threads in the pool and executed while we continue scanning and filtering. Unrelated to the current issue, we have a completion phase at the end of the scanning that ensures all the forked tasks have been executed. To sum it up, we have a single task that scans some data and forks lots of processing task. Previously (with the version from a few months back without the worker queues), this was working perfectly and al</pre> Romain Colle 2012-05-22T16:20:47 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9496 <pre>Hi, all Here is some lines of comments in ThreadLocalRandom.java // Padding to help avoid memory contention among seed updates in // different TLRs in the common case that they are located near // each other. What's the above TLR short for ? Thanks, Min </pre> Min Zhou 2012-05-21T07:43:42 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9486 <pre>Hi, What are the odds of getting a Promise implementation in j.u.c.? I occasionally find myself needing something like that. I'm thinking it could perhaps look a bit like this (to show a concrete example of an API): https://github.com/chrisvest/concurrency-extras/blob/master/src/main/java/javax/util/concurrent/Promise.java Cheers, Chris _______________________________________________ Concurrency-interest mailing list Concurrency-interest&lt; at &gt;cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest </pre> Chris Vest 2012-05-19T12:45:48 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9467 <pre>as reported on http://stackoverflow.com/questions/10620680 basically there are volatile int a; int b; Thread 1: b=1; a=1; Thread 2: while(a==0) ; if(b==0) print("error"); "error" is seen printed on 32 bit JDK6 on 64bit machine </pre> Zhong Yu 2012-05-16T16:55:00 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9444 <pre>People may find this upcoming paper interesting by a notable researcher and from a multicore research group: Can Parallel Data Structures Rely on Automatic Memory Managers? Erez Petrank Dept. of Computer Science Technion, Israel erez&lt; at &gt;cs.technion.ac.il http://safari.ece.cmu.edu/MSPC2012/erez_abstract.pdf MSPC’12, June 16, 2012, Beijing, China. ABSTRACT The complexity of parallel data structures is often measured by two major factors: the throughput they provide and the progress they guarantee. Progress guarantees are particu- larly important for systems that require responsiveness such as real-time systems, operating systems, interactive systems, etc. Notions of progress guarantees such as lock-freedom, wait-freedom, and obstruction-freedom that provide di er- ent levels of guarantees have been proposed in the literature [4, 6]. Concurrent access (and furthermore, optimistic ac- cess) to shared objects makes the management of memory one of the more complex aspects of concurrent algorithms design. The us</pre> Kimo Crossman 2012-05-15T03:24:05 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9415 <pre>Hi, I could not find any resources that I felt were clear and trustworthy enough, so... I would like to have confirmed (or busted) my assumption that the following code is buggy, because the garbage collector might set the `a` field to null, before this `finalize` method can read it, thus preventing the method from attempting to cleanly dispose of the `Resource` in the `b` field — this all under the assertion that `safelyDispose` itself never throws: public class SomeService { private final Resource a, b; public SomeService(Resource a, Resource b) { assert a != null &amp;&amp; b != null; this.a = a; this.b = b; } &lt; at &gt;Override protected void finalize() throws Throwable { a.safelyDispose(); b.safelyDispose(); } } Cheers, Chris _______________________________________________ Concurrency-interest mailing list Concurrency-interest&lt; at &gt;cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest </pre> Chris Vest 2012-05-13T20:22:21 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9414 <pre>Hi there. I wrote a JUnit runner that attempts to annihilate any threads that leaked out of a given test's scope. The process starts by setting an interrupt flag, then after some delay it just calls Thread.stop() (let's not go into why this particular method was chosen for now, I realize the consequences). Anyway. I've encountered an interesting scenario where a ThreadPoolExecutor is used in combination with ExecutorCompletionService (in Apache Lucene). What happens is that the thread pool's threads are first interrupted (which doesn't terminate thread pool threads, they are reused) and then stopped, which does seem to kill them (I see uncaught stacks: java.lang.IllegalMonitorStateException at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:155) at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1260) at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:460) at java.util.concurrent.LinkedBlockingQueue.take(Linke</pre> Dawid Weiss 2012-05-13T20:08:31 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9392 <pre>Hey, How about this for inclusion in JDK8? /** * The RejectedExecutionHandler used by Akka, it improves on CallerRunsPolicy * by throwing a RejectedExecutionException if the executor isShutdown. * (CallerRunsPolicy silently discards the runnable in this case, which is arguably broken) */ class CallerRunsOrRejects extends RejectedExecutionHandler { def rejectedExecution(runnable: Runnable, threadPoolExecutor: ThreadPoolExecutor): Unit = { if (threadPoolExecutor.isShutdown) throw new RejectedExecutionException("Shutdown") else runnable.run() } } Cheers, √ </pre> √iktor Ҡlang 2012-05-12T16:39:49 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9375 <pre>Hey guys, I'd like to explore alternatives to ConcurrentLinkedQueue, especially to get a bit lower latency and perhaps even lower mem usage. Behavior: No locks Unbounded Single consumer Multiple producers Operations: dequeue enqueue numberOfMessages // Would be nice to have as a constant, can be linear or simply not supported, doesn't really matter hasMessages // Just a Boolean if there's anything in there at all, only needs to return true if something has been put in that hasn't been pulled out yet Is there anything out there which is better than CLQ? Cheers, √ </pre> √iktor Ҡlang 2012-05-11T15:00:21 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9363 <pre>Hello all, I'm looking for a thread pool with the following characteristics... (in pseudo-code) interface StripedRunner { Object getStripeClass(); void run(); } magicPool.execute( stripedRunner ); The idea being that any StripedRunners with the same stripeClass would get executed in the order they were queued, but StripedRunners with different stripedClasses could execute independently. Is there a way to configure the standard concurrent pools to work this way (doesn't seem to be), or a way to extends the current code? Or perhaps some third party library implementation? Thanks! Glenn McGregor _______________________________________________ Concurrency-interest mailing list Concurrency-interest&lt; at &gt;cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest </pre> Glenn McGregor 2012-05-11T04:53:46 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9334 <pre>Sorry if this is a stupid question regarding fork-join pools, but I am not sure wheter the "lightweigth future" idea would also work async http calls. (And please also excuse my bad english) Currently I use the ning asnyc-http-client ( https://github.com/sonatype/async-http-client) in an event-driven callback style to do nonblocking http-calls from a servlet. However the callback style gets a bit complicated when the program-logic gets complex so I wonder wheter I could use ForkJoinTask to transfer the callback style to non-thread-blocking futures. The idea is to initialize the nonblocking HttpCall in ForkJoinTaks.exec() and when the callback receives the http-response it calls the ForkJoinTaks.complete() method. Maybe someone can take a look at the following ForkJoinTask which wraps an HttpCall and say wheter it is a reasonable use of ForkJoinPool. import com.ning.http.client.AsyncHttpClient; import com.ning.http.client.AsyncCompletionHandler; import com.ning.http.client.Response; //The forkjoin task </pre> Christian Essl 2012-05-06T21:58:23 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9328 <pre>I've been thinking about what to do with Intel's Hardware Lock Elision (HLE), if anything. Briefly, HLE allows locked regions to proceed transactionally, so something like Hashtable's public synchronized V put(K key, V value) { ... } could proceed in parallel with other cores accessing the same Hashtable, as long as there were no conflict with the same hash slot. If any unsafe instructions (interrupts, I/O, etc.) were executed or if there were a conflict with another thread, the hardware would abort the transaction (i.e. discard all pending memory updates and automagically fall back to locking). If there were no conflict, all threads would proceed in parallel, and all accesses to the lock would be elided. In theory this could be used for Java. There is, as far as I can see, one significant downside: if conflicts are highly probable, there will be a performance degradation because speculation on transactions that will abort wastes CPU cycles. Also, I was worried that this might not actu</pre> Andrew Haley 2012-04-25T11:35:25 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9287 <pre>Hi guys, I'm trying to workaround the FutureTask race described in CR 7132378: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132378 I do realize the fix is already there in Doug's code, but both waiting for JDK update or bootclasspath-ing jsr166.jar is not an option for this particular case I'm dealing with. Hence, my question is: can this code be considered a proper workaround? /** * Specialized form of future allowing to set the result. * * &lt; at &gt;param &lt;V&gt; */ public class SettableFuture&lt;V&gt; extends FutureTask&lt;V&gt; { /** * Implementation notes: * * This implementation also accounts for known bug in FutureTask: * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7132378 * * We compensate for possible race by making sure set() had * completed before returning from get(). Since get() is * blocking operation, we first wait without any synchronization, * and then do get() again synchronizing with set() to make sure * set() had indeed completed. *</pre> Aleksey Shipilev 2012-04-20T08:29:57 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9284 <pre>Hi guys, There are multiple cases now when people are choosing ForkJoinPool over regular ThreadPoolExecutor because of improved submission throughput and work balancing. Can we embrace this fact and do proper isolation in API for this cases? I'm thinking public class j.u.c.WorkStealingExecutor implementing ExecutorService, but delegating directly to ForkJoinPool. If that is added to JDK7/JDK8, we can properly isolate these customers from exposing FJP underneath. Moreover, after this API is exposed, we can gradually replace FJP delegation with independent work-stealing executor, if ties with FJP will bother anyone. Are there any troubles with this proposal I missed? -Aleksey. </pre> Aleksey Shipilev 2012-04-19T15:14:59 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9272 <pre>Hi all, I have been looking for the right way to build an API that returns a Future that is composed of tasks that will be performed in multiple stages, potentially from more than one thread. My use cases is a disk based persistence store. The initial put API call creates a task that compresses and checksums the payload. The resulting Future is bound in a Runnable and submitted to a single thread ExecutorService that timestamps the entry and appends it to a file and it is the Future of the second task that is currently returned by the API. The trick is that the Future that is returned by the put call should not complete until the write is durable. Writes are made durable by periodically invoking fsync from a dedicated thread or by rotating write threads as each blocks on fsync/force. This allows for group commit at an interval the IO device can handle without killing throughput. Ideally I could create a FutureTask that is composed of several other Futures, some of which will not exist when the Futu</pre> Ariel Weisberg 2012-04-17T15:39:56 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9260 <pre>Hi, all, I tried to use the newest version of ForkJoinPool from the cvs repository of jsr166y to replace the old ExecutorService on our RPC project opensource at http://code.google.com/p/nfs-rpc/ . The modification is quite slight. Here is the diff Index: nfs-rpc-common/src/main/java/code/google/nfs/rpc/NamedForkJoinThreadFactory.java =================================================================== --- nfs-rpc-common/src/main/java/code/google/nfs/rpc/NamedForkJoinThreadFactory.java (revision 0) +++ nfs-rpc-common/src/main/java/code/google/nfs/rpc/NamedForkJoinThreadFactory.java (revision 0) &lt; at &gt;&lt; at &gt; -0,0 +1,48 &lt; at &gt;&lt; at &gt; +package code.google.nfs.rpc; +/** + * nfs-rpc + * Apache License + * + * http://code.google.com/p/nfs-rpc (c) 2011 + */ +import java.util.concurrent.atomic.AtomicInteger; + +import code.google.nfs.rpc.jsr166y.ForkJoinPool; +import code.google.nfs.rpc.jsr166y.ForkJoinPool.ForkJoinWorkerThreadFactory; +import code.google.nfs.rpc.jsr166y.ForkJoinWorkerThread; + +/** + * Helper class to let user</pre> Min Zhou 2012-04-17T10:30:17 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9242 <pre>Hi All,   I have found a way of preventing deadlocks in java. The methodology(which is code) completely prevents the deadlock from accuring by detecting it in advance. This can be used across the systems seamlessly.   Kindly let me know what I need to do next. I want this to be part of next jdk release.   Thanks &amp; Regards, Rohit Kumar_______________________________________________ Concurrency-interest mailing list Concurrency-interest&lt; at &gt;cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest </pre> Rohit Kumar 2012-04-16T11:03:59 http://comments.gmane.org/gmane.comp.java.jsr.166-concurrency/9232 <pre> After sitting on multiple variations for months, I committed CountedCompleter, a completion-based flavor of ForkJoinTask. As mentioned a few times over the past year, the main motivation is to better support tasks that perform IO or other base actions that may (or may not) take a lot of time to execute. As is the case with JDK7 async IO and other completion-based frameworks, the most common path to efficiency is for such tasks to arrange continuation actions that occur upon their completion. The main twist for CountedCompleters is that continuations might be dependent on multiple actions, not just one. (Or in other words, the continuations must be preceded by a specialized, "bottom-up" form of join.) The CountedCompleter abstract class provides a minimal basis for these kinds of tasks. While some of the mechanics are reminiscent of other FJ-like frameworks such as Intel TBB, CountedCompleters are designed to fit smoothly with other kinds of ForkJoinTasks (like RecursiveActions), and so still allow people </pre> Doug Lea 2012-04-09T14:16:01 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.java.jsr.166-concurrency