New answers tagged

4

Comments turned into an answer: You are right to worry about performance with locking everything under one mutex, but the better solution is to make sure there is as little going on as possible inside the lock. Thread 1 should have the value and index ready and really only be doing a single write. Thread 2 would operate on an unshared local instance of the ...


2

In your particular case (all variables being scalars, i.e. integral or boolean) you might consider using the atomic facilities of C++11. You need a recent GCC or Clang compiler. So you would use std::atomic_bool and e.g. std::atomic_int etc... for the types of these variables and use atomic_load & atomic_store. A simple usage would be to systematically ...


1

IMO threads can be split into three main categories. Long running threads that monitor one thing per thread. Putting a limit on these will limit the number of things you can monitor which is likely not what you want to do. If you do put a limit it should be very high and mostly a sanity check. Threads that spend most of their time on computation. You ...


3

I would suggest you rather use a Win Form app for game. If you use Console you will need to refresh (clear and redraw) the console each time you want to change display - that is with change in each second. On a win form you can directly put a timer control and start the timer on game start (button click, form load - as per your need). When timer tick event ...


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 ...


2

The problem that you have is that you're looking at simplified example, which is so far simplified that you've entirely removed the immutable state from it and left only a single (albeit atomic) mutable value. That's not a realistic example of an immutable system. To bring some immutability back into it, consider a different example. Two threads are ...


2

Aren't locks only needed if you're changing state? There is a subtlety here. Locks are needed not only if the current thread wants to modify the state, but if any any other thread might modify the state. This means that you can only safely elide the object if you know that no other part of the system will modify it. In other words, you can only elide ...


7

So I think that we need to eliminate the term "shared state" from your question, because shared state is almost diametrically opposed to the notion of using immutability to avoid locking. In your example, you basically said that both read some value "N" and both create a new object with a value "N+1". The key is that you wouldn't necessarily save the value ...


3

What happens when two threads are trying to generate a new shared state? Let's be clear about what I understand your question to be: You have some mutable variable of immutable state. Let's use an int for simplicity: int x = 42; Then you want two threads to both try to increment x by 1. Then you get to synchronize them. Immutability provides little ...


1

The answer is pretty easy, with immutability, you don't change state rather you create new state(s). So you have 2 processes both getting input from the same state. What you end up with is 3 things: first the original state, and 2 new states which is the output from the 2 processes. What you need now is a third process dedicated to putting those states ...


-1

That's not how it works. If you have two threads reading and incrementing a shared variable, it's not immutable. When you mark something as immutable, you're telling everyone (and yourself) that the value isn't going to change.



Top 50 recent answers are included