New answers tagged

2

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


-1

JAVA: Create Spring's ThreadPoolExecutor for all of you different tasks. Just submit task to ThreadPoolExecutor whenever you get the task. Provide queue Size according to your need, if you are not sure provide INT_MAX. Most Imp - For perfect/fastest design, make sure different tasks are independent and you dont need to use synchronization or very minimum ...


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.


1

Don't use Pthread mutexes to synchronize between processes, at least on Linux. (I am not sure that Linux is implementing pthread_mutexattr_setpshared correctly and efficiently, at least not in GNU glibc 2.21). Use POSIX semaphores, see sem_overview(7). Or consider the Linux specific eventfd(2) probably with poll(2) & read(2) & write(2). Both ...


1

If I were you, I'd forget about using either pthreads (which only works on threads and not processes, and you're clearly using multiple processes) or shared memory of the kind you're talking about, as transferring the handles between processes is going to be a bit of a pain point when working in C#. A simpler technique, which is becoming increasing frequent ...


2

pthread_mutex_t is not designed to work cross process like that. It was built with the assumption that all threads using it will have the same address space. There are however other options to share a mutex between processes. As discussed in the comments there is futex(7) (which will work over shared memory) and sem_overview(7) (an explicit named semaphore ...


1

The design pattern that most closely matches your description would be a Producer Consumer pattern with a queue between each side. For your exact specs you would have 4 threads consuming the queue which will limit to 4 items being worked on at one time. Depending on the language there may be built in constructs for multi threaded queue concurrency (C# ...


9

Atomic access does not translate into thread-safe behavior. One example is when a global data structure needs to be invalid during an update like rehashing a hashmap (when adding a property to an object for example) or sorting a global array. During that time you cannot allow any other thread to access the variable. This basically means that you need to ...


70

1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is. At the moment, it sounds like you're simply "adding threads" to the language and worrying about how to make it correct and performant later. In particular: if two tasks try to access a variable ...


15

Just guessing here to demonstrate a problem in your approach. I can't test it against the real implementation as there is no link anywhere... I'd say it is because invariants are not always expressed by the value of one variable, and 'one variable' is not sufficient to be the scope of a lock in the general case. For example, imagine we have an invariant ...


1

This is needed. The lack of a low level concurrency mechanism in node js limits it's applications in fields such as math and bioinformatics, etc... Besides, concurrency with threads doesn't necessarily conflict with the default concurency model used in node. There are well known semantics for threading in an environment with a main event loop, such as ui ...


14

A decade or so ago Brendan Eich (the inventor of JavaScript) wrote an essay called Threads Suck, which is definitely one of the few canonical documents of JavaScript's design mythology. Whether it is correct is another question, but I think it had a big influence on how the JavaScript community thinks about concurrency.


6

Is your approach going to significantly improve performance? Doubtful. You really need to prove this. Is your approach going to make it easier/faster to write code? Definitely not, multithreaded code is many times harder to get right than single threaded code. Is your approach going to be more robust? Deadlocks, race conditions etc. are a nightmare to ...


2

Your implementation is not just about introducing concurrency, rather its about introducing a specific way to implement concurrency i.e concurrency by shared mutable state. Over the course of history people have used this type of concurrency and this has lead to many kinds of problems. Ofcourse you can create simple programs that works perfectly with using ...


0

I really believe it's because it's a different and powerful idea. You are going against belief systems. Stuff becomes accepted or popular through network affects not on the basis of merit. Also no one wants to adapt to a new stack. People automatically reject things that are too different. If you can come up with a way to make it into a regular npm ...


13

The book you are reading was published in 2007. The C++ API for managing threads wasn't standardised until 2011. At the time, on different systems you had to use entirely different platform-specific libraries (pthreads, win32 threads, etc). Now, this is no longer true. Your book is out of date.


5

... threading is platform-dependent, can someone explain, why? The platform dependencies are typically differences in the way that the thread scheduler works. The fact is that thread schedulers do behave differently on different platforms due to: differences in the thread scheduler algorithms across different operating systems and versions. ...



Top 50 recent answers are included