I tried something, and it seems to work. I put preload_app = True in my gunicorn.conf and now the lock seems to be shared. I am still looking into exactly what’s happening here but for now this is good enough, YMMV.
A CompletableFuture is not related to the asynchronous action that may eventually complete it. Since (unlike FutureTask) this class has no direct control over the computation that causes it to be completed, cancellation is treated as just another form of exceptional completion. Method cancel has the same effect as completeExceptionally(new CancellationException()). There may not even … Read more
When you use NSPrivateQueueConcurrencyType you need to do anything that touches that context or any object belonging to that context inside the -performBlock: method. Your code above is illegal since you’re passing those objects back to the main queue. The new API helps you in solving this, though: You create one context that’s associated with … Read more
I just ran into a similar scenario (“I am interested in a fast Add and Contains and Remove”) and implemented this sucker: using System.Collections.Generic; using System.Threading; namespace BlahBlah.Utilities { public class ConcurrentHashSet<T> : IDisposable { private readonly ReaderWriterLockSlim _lock = new ReaderWriterLockSlim(LockRecursionPolicy.SupportsRecursion); private readonly HashSet<T> _hashSet = new HashSet<T>(); #region Implementation of ICollection<T> …ish public … Read more
Using a ExecutorCompletionService.poll/take, you are receiving the Futures as they finish, in completion order (more or less). Using ExecutorService.invokeAll, you do not have this power; you either block until are all completed, or you specify a timeout after which the incomplete are cancelled. static class SleepingCallable implements Callable<String> { final String name; final long period; … Read more
The main difference between AtomicBoolean and volatile from a practical point of view is that the compare-and-set operation isn’t atomic with volatile variables. volatile boolean b; void foo() { if( b ) { //Here another thread might have already changed the value of b to false b = false; } } But seeing as all … Read more
Yes. Reads and writes of the following data types are atomic: bool, char, byte, sbyte, short, ushort, uint, int, float, and reference types. as found in C# Language Spec. Edit: It’s probably also worthwhile understanding the volatile keyword.
mo_relaxed is fine for both load and store of a stop flag There’s also no meaningful latency benefit to stronger memory orders, even if latency of seeing a change to a keep_running or exit_now flag was important. IDK why Herb thinks stop.store shouldn’t be relaxed; in his talk, his slides have a comment that says … Read more
The only way to combine multiple stages that scales well with a growing number of stages, is to use CompletableFuture. If your CompletionStages aren’t CompletableFutures you may still convert them using .toCompletableFuture(): CompletableFuture<A> aCompletionStage = getA().toCompletableFuture(); CompletableFuture<B> bCompletionStage = getB().toCompletableFuture(); CompletableFuture<C> cCompletionStage = getC().toCompletableFuture(); CompletableFuture<D> dCompletionStage = getD().toCompletableFuture(); CompletionStage<Combined> combinedDataCompletionStage = CompletableFuture.allOf( aCompletionStage, bCompletionStage, cCompletionStage, … Read more
The C++11 memory ordering parameters for atomic operations specify constraints on the ordering. If you do a store with std::memory_order_release, and a load from another thread reads the value with std::memory_order_acquire then subsequent read operations from the second thread will see any values stored to any memory location by the first thread that were prior … Read more