concurrency

问题 Here are two potential workflows I would like to perform in a web application. Variation 1 user sends request server reads data server modifies data server saves modified data Variation 2: user sends request server reads data server sends data to user user sends request with modifications server saves modified data In each of these cases, I am wondering: what are the standard approaches to ensuring that concurrent access to this service will produce sane results? (i.e. nobody's edit gets

问题 I am new to Golang. Right now I am trying to figure out how to make an any-to-one channel in Golang, where the setup is as follows: say I have two goroutines numgen1 and numgen2 executing concurrently and writing numbers to channels num1 resp. num2. I would like to add the numbers sent from numgen1 and numgen2 in a new process, addnum. I have tried something like this: func addnum(num1, num2, sum chan int) { done := make(chan bool) go func() { n1 := <- num1 done <- true }() n2 := <- num2 <-

问题 I have a a concurrency issue I tried to solve with a while loop that attempts to save an entity multiple times until it hits some max retry count. I'd like to avoid talking about whether or not there are other ways to solve this problem. I have other Stackoverflow posts about that. :) Long story short: there's a unique constraint on a column that is derived and includes a numeric portion that keeps incrementing to avoid collisions. In a loop, I: select max(some_value) increment the result

问题 I need to use memcached Java API in my Scala/Akka code. This API gives you both synchronous and asynchronous methods. The asynchronous ones return java.util.concurrent.Future. There was a question here about dealing with Java Futures in Scala here How do I wrap a java.util.concurrent.Future in an Akka Future?. However in my case I have two options: Using synchronous API and wrapping blocking code in future and mark blocking: Future { blocking { cache.get(key) //synchronous blocking call } }

问题 When using the ExecutorService returned by Executors.newSingleThreadExecutor() , how do I interrupt it? 回答1: In order to do this, you need to submit() a task to an ExecutorService , rather than calling execute() . When you do this, a Future is returned that can be used to manipulate the scheduled task. In particular, you can call cancel(true) on the associated Future to interrupt a task that is currently executing (or skip execution altogether if the task hasn't started running yet). By the

问题 Is it possible at runtime to programmatically check the name of the Thread that is holding the lock of a given object? 回答1: You can only tell whether the current thread holds a normal lock (Thread.holdsLock(Object)). You can't get a reference to the thread that has the lock without native code. However, if you're doing anything complicated with threading, you probably want to familiarize yourself with the java.util.concurrent packages. The ReentrantLock does allow you to get its owner (but

问题 Is it possible at runtime to programmatically check the name of the Thread that is holding the lock of a given object? 回答1: You can only tell whether the current thread holds a normal lock (Thread.holdsLock(Object)). You can't get a reference to the thread that has the lock without native code. However, if you're doing anything complicated with threading, you probably want to familiarize yourself with the java.util.concurrent packages. The ReentrantLock does allow you to get its owner (but

问题 I want to implement my particle filtering algorithm in parallel in Common Lisp. Particle Filtering and sampling can be parallelized and I want to do this for my 4-core machine. My question is whether programming in parallel is feasible in CL or not and if it is feasible are there any good readings, tutorials about getting started to parallel computing in CL. 回答1: Definitely feasible! The Bordeaux Threads project provides thread primitives for a number of implementations; I would suggest using

问题 When using futures in scala the default behaviour is to use the default Implicits.global execution context. It seems this defaults to making one thread available per processor. In a more traditional threaded web application this seems like a poor default when the futures are performing a task such as waiting on a database (as opposed to some cpu bound task). I'd expect that overriding the default context would be fairly standard in production but I can find so little documentation about doing

问题 new SynchronousQueue() new LinkedBlockingQueue(1) What is the difference? When I should use SynchronousQueue against LinkedBlockingQueue with capacity 1? 回答1: the SynchronousQueue is more of a handoff, whereas the LinkedBlockingQueue just allows a single element. The difference being that the put() call to a SynchronousQueue will not return until there is a corresponding take() call, but with a LinkedBlockingQueue of size 1, the put() call (to an empty queue) will return immediately. I can't