concurrency

问题 I've been using NSLock s to synchronize touchy parts of code, but have been running into issues due to the fact that they must be unlocked from the same thread that they were locked from. Then I found that GCD's DispatchSemaphore s seem to do the same thing, with the added convenience that they can be signaled from any thread. I was wondering, though, if this convenience comes at the price of thread-safety. Is it advisable to replace let lock = NSLock() lock.lock() // do things... lock.unlock

问题 I need to copy a file from one location to another, and I need to throw an exception (or at least somehow recognise) if the file already exists at the destination (no overwriting). I can check first with os.path.exists() but it's extremely important that the file cannot be created in the small amount of time between checking and copying. Is there a built-in way of doing this, or is there a way to define an action as atomic? 回答1: There is in fact a way to do this, atomically and safely,

问题 I'm a go-newbie, so please be gentle. So I've been using mutexes in some of my code for a couple weeks now. I understand the concept behind it: lock access to a certain resource, interact with it (read or write), and then unlock it for others again. The mutex code I use is mostly copy-paste-adjust. The code runs, but I'm still trying to wrap my head around it's internal working. Until now I've always used a mutex within a struct to lock the struct. Today I found this example though, which

问题 I'm studying Java Concurrency in Practice and there it is explained why the following snippet of code is bad: public class NoVisibility { private static boolean ready; private static int number; private static class ReaderThread extends Thread { public void run() { while (!ready) { Thread.yield(); System.out.println(number); } } public static void main(String[] args) { new ReaderThread().start(); number = 42; ready = true; } } This code may print 0 or loop forever. While it is easy to

问题 The AtomicInteger's decrementAndGet does not seems working correctly in multi-threaded operation. Though the incrementAndGet works correctly. I run this program from the Executors and in 10 threads. Each thread is decrementing the value 5 times in the loop so 10 threads will reduce its value to -50. But I do not get the value -50. Same thing if I do for calling incrementAndGet then, it does increase to 50. public class RunCountAtomic { public static AtomicInteger aValue = new AtomicInteger(0)

问题 I have a TextArea in which the user of my app can write things. A ChangeListener is also listening to the StringProperty "text" of this TextArea . Whenever the text content changes, ChangeListener.changed() , among other things, sets a "dirty" BooleanProperty to true on a central app object. Where "dirty" has the sense of "document needs saving". But I've just implemented a thing in my app whereby any time that the "dirty" Property gets set to true triggers a save-file-to-disk action,

问题 I get the feeling this may be a very general and common situation for which a well-known no-lock solution exists. In a nutshell, I'm hoping there's approach like a readers/writer lock, but that doesn't require the readers to acquire a lock and thus can be better average performance. Instead there'd be some atomic operations (128-bit CAS) for a reader, and a mutex for a writer. I'd have two copies of the data structure, a read-only one for the normally-successful queries, and an identical copy

问题 I get the feeling this may be a very general and common situation for which a well-known no-lock solution exists. In a nutshell, I'm hoping there's approach like a readers/writer lock, but that doesn't require the readers to acquire a lock and thus can be better average performance. Instead there'd be some atomic operations (128-bit CAS) for a reader, and a mutex for a writer. I'd have two copies of the data structure, a read-only one for the normally-successful queries, and an identical copy

问题 The Java image API assumes asynchronous loading. Various methods take an ImageObserver as a parameter which might get informed once the image is completely loaded. On the other hand some types of images (e.g. BufferedImages) don't use the ImageObserver and will never call it. So how would code look that waits until an image is fully loaded? I'd like to have a method like public void waitUntilLoaded(Image img){ ... } Which guarantees that the image is completely loaded when it returns. 回答1: A

问题 Reading the Java 8 documentation about the java.util.concurrent.locks.Condition interface, the following example is given: class BoundedBuffer { final Lock lock = new ReentrantLock(); final Condition notFull = lock.newCondition(); final Condition notEmpty = lock.newCondition(); final Object[] items = new Object[100]; int putptr, takeptr, count; public void put(Object x) throws InterruptedException { lock.lock(); try { while (count == items.length) notFull.await(); items[putptr] = x; if (+