New answers tagged

3

It's not the Java language. It's the nature of locks (mutexes). There are better ways to get improved concurrency while still guaranteeing correctness, ways that are language independent: Using immutable objects, so that you don't need locks. Using promises and continuation-passing style. Using lock-free data structures. Using Software Transactional ...


0

I can see #3 introducing some potentially nasty race conditions, and even #1 could suffer from a race condition if the schema update happens right after another instance has connected to the database. If you borrow a technique from Active Record migrations and designate a table to keep track of the schema version, not only can you safely lock on that table, ...


3

Only option three Carefully wrapping each non-idempotent statement in checks. has any appeal for me. This option is the only one that doesn't require the script to depend on anything else (hardware, software or otherwise) for its proper function.


0

Separate writes and reads. Below is a way to allow both to occur at the same time to the same file. Maybe you need for writing or changing the state of the media. It has a list of writers and a parallel list of states. If the write fails beacuse it violates an invaraint, change the state. It would notify observers list with the state. The medium state ...


0

Is it possible and feasible to split the serialised data into parts? One part containing the stable part of the state and one small part containing the changing part of the state. This way you have several options: you can serialise the small changing part last; you can use events, observer pattern or reactive paradigm to serialise the changing part of ...


23

A better concurrency story is one of the main goals of the Rust project, so improvements should be expected, provided we trust the project to achieve its goals. Full disclaimer: I have a high opinion of Rust and am invested in it. As you do in the question I'll try to avoid value judgements and describe differences rather than (IMHO) improvements. Safe and ...


3

Your examples are not semantically equivalent: Observable<T> observable = getData() observable.subscribe(onSuccess, onError, onCompletion) will execute the onSuccess, onError procedures each time a new element is received. On the other hand, with Iterable<Future<T>> futures = getData() futures.forEach(future => ...


0

Your question can be easily implemented using a distributed cache like NCache. What you require is a Pessimistic Locking mechanism where you could Acquire a lock using an object. Then perform your tasks and operations and release the lock for other applications to consume later on. Take a look at the following code; Here you would acquire a lock on a ...


4

The Guava Library has the concept of a ListenableFuture and a SettableFuture. A ListenableFuture allows you to register callbacks to be executed once the computation is complete, or if the computation is already complete, immediately. This simple addition makes it possible to efficiently support many operations that the basic Future interface cannot ...



Top 50 recent answers are included