Well – best practice is that structs should always (except in a few very specific scenarios, and even then at risk) be immutable. And immutable data is always thread safe. So if you followed best practice and made this: struct Data { readonly int _number; public int Number { get { return _number; } } … Read more
FWIW, there are many synchronization techniques that offer better performance than semaphores. For example, you can use the reader-writer pattern with concurrent queue, where reads are done synchronously, but are allowed to run concurrently with respect to other reads, but writes are done asynchronously, but with a barrier (i.e. not concurrently with respect to any … Read more
Recovering doesn’t work here because what you experience is not a panicing state. Go 1.6 added a lightweight concurrent misuse of maps detection to the runtime: The runtime has added lightweight, best-effort detection of concurrent misuse of maps. As always, if one goroutine is writing to a map, no other goroutine should be reading or … Read more
Unfortunately, this isn’t supported by the boost::interprocess API as-is. There are a few ways you could implement it however: If you are on a POSIX platform with support for pthread_mutexattr_setrobust_np, edit boost/interprocess/sync/posix/thread_helpers.hpp and boost/interprocess/sync/posix/interprocess_mutex.hpp to use robust mutexes, and to handle somehow the EOWNERDEAD return from pthread_mutex_lock. If you are on some other platform, you … Read more
Maybe it’s easier for me to interpret because I wrote that code, but it’s not so hard, just look at the first line of the error output: swap.cpp:22:14: error: invalid use of incomplete type ‘class std::future<std::basic_string<char> >’ That’s telling you that std::future is an incomplete type, i.e. it is declared but not defined. The next … Read more
Basically, you’re just implementing a spinlock. Only instead of one lock variable, you have an entire texture’s worth of locks. Logically, what you’re doing makes sense. But as far as OpenGL is concerned, this won’t actually work. See, the OpenGL shader execution model states that invocations execute in an order which is largely undefined relative … Read more
If you have CPU bound tasks, as you increase the number of threads you get increasing overhead and slower performances. Note: having more threads than waiting tasks is just a waste of resources, but may not slow down the tasks so much. I would use a multiple (e.g. 1 or 2) of the number of … Read more
The reason why this is possible is that Java has a weak memory model. It does not guarantee ordering of read and writes. This particular problem can be reproduced with the following two code snippets representing two threads. Thread 1: someStaticVariable = new Holder(42); Thread 2: someStaticVariable.assertSanity(); // can throw On the surface it seems … Read more
ASP.NET Core application concurrency is handled by its web server. For example: Kestrel var host = new WebHostBuilder() .UseKestrel(options => options.ThreadCount = 8) It is not recommended to set Kestrel thread count to a large value like 1K due to Kestrel async-based implementation. More info: Is Kestrel using a single thread for processing requests like … Read more
Make me think of a sequence lock. Not very accurate (putting this from memory) but something along the lines of: let x,y and s be 64 bit integers. To increment: atomic s++ (I mean atomic increment using 64 bit CAS op) memory barrier atomic x++ atomic y++ atomic s++ memory barrier To read: do { … Read more