[concurrency-interest] Concurrent sequential access to a mutable field without the volatile modifier
aph at redhat.com
Fri Jan 7 12:56:56 EST 2011
On 01/07/2011 05:47 PM, Sébastien Bocq wrote:
> 2011/1/7 Marco Villalobos<mvillalobos at kineteque.com>
>> It is very difficult to prove that thread unsafe code or bad
>> concurrency will fail.
>> For example, I once deliberately wrote a thread unsafe unique word
>> counter. I had it count the words in the complete bible (all of the
>> books with separate files) and all of the Shakespeare books.
>> It rarely ever failed, even though it was thread unsafe.
>> Threads need to be taken in and of context in middle of an operation
>> while another takes over to expose errors.
>> These types of situations occur more commonly on multi-processor
>> systems and/or a stressed system.
>> You can kind of force this situations by introducing a
>> Thread.currentThread().sleep() at right places in your code for
>> testing purposes.
> Yes, I've been there too. I had a similar project at university: everything
> went fine until I gave out the code to the examiner :-)
> I hope in the future we will have better means to test concurrent software.
> It could be a JVM dedicated to concurrent testing with a terrible
> performance but that caches everything not correctly synchronized and
> inserts tiny sleep statements randomly.
The best thing it could do would be to save all memory stores into a
local soft cache and not write out anything until the next memory
barrier. Then, it could write out all the stores in a random (or
reverse!) order. :-)
I wonder just how many bugs that would reveal!
More information about the Concurrency-interest