Tag Info

New answers tagged

2

Producing a useful static analysis tool involves balancing a number of conflicting concerns, including at least the following: False positive (false alarm) rate False negative (uncaught bug) rate Run time and scalability False positives are a critical concern with bug detection tools since they waste developer time. It's possible to eliminate false ...


4

In my experience, a determined, well-meaning, but clueless developer can wrap enough obfuscation around a concurrency bug that the analysis tool will miss it. If the tool thinks there's a bug, assume it's right until you prove otherwise. That's the value of the tool. If the tool doesn't find any bugs, your best bet is to pretend the tool doesn't exist. ...


2

Answering your first question: http://www.contemplateltd.com/threadsafe/faq#non-checkers "What kinds of concurrency defects does ThreadSafe not look for? We do not yet include support for all of java.util.concurrent. Specifically, ThreadSafe does not check for misuse of the advanced synchronization facilities provided by java.util.concurrent, for example ...


0

Use a different channel on a message queue for each consumer. For each line in one of your big files write a message to each channel (e.g. each consumer). Each consumer can process messages on its channel deleting the messages once received.


1

It is not possible that two (or more) threads acquire lock on the same time. There are few types of synchronization methods for instance: Active waiting - spin lock Pseudocode: 1. while ( xchg(lock, 1) == 1); - entry protocole XCHG is an example of atomic operation (exists on x86 architecture) which first sets new value for a "lock" variable and then ...


2

Simply put the code to get into the critical section is specially designed so a race condition won't violate the mutual exclusion. Most of the time atomic compare and set loops are used that execute at the hardware level while(!CompareAndSet(&lock, false, true));//busy loop won't continue until THIS thread has set the lock to true //critical section ...


15

Study the concept of atomic "Test and Set" operations. Essentially the operation cannot be divided - it is not possible for two things to do it at exactly the same time. It will check a value, set it if it is clear, and return the value as it was when test. In a lock operation, the result will always be "lock == TRUE" after a test-and-set, the only ...


32

Is it impossible, or just plain unlikely? Impossible. It can be implemented in different ways, e.g., via the Compare-and-swap where the hardware guarantees sequential execution. It can get a bit complicated in presence of multiple cores or even multiple sockets and needs a complicated protocol between the cores, but this is all taken care of.


5

From this article about CoralQueue: The disruptor pattern is a batching queue backed up by a circular array (i.e. the ring buffer) filled with pre-allocated transfer objects which uses memory-barriers to synchronize producers and consumers through sequences. So producers and consumers do not step on each other inside the circular array by ...


10

The Fowler Article providers a good primer, and this explanation: At a crude level you can think of a Disruptor as a multicast graph of queues where producers put objects on it that are sent to all the consumers for parallel consumption through separate downstream queues. When you look inside you see that this network of queues is really a single ...



Top 50 recent answers are included