[concurrency-interest] Spot the bug in stream processing, IntConsumer and Executor

kedar mhaswade kedar.mhaswade at gmail.com
Fri Feb 24 23:53:53 EST 2017


​Perhaps I had a long day. So, this might completely be a silly mistake,
but I need congenial help to figure it out.

To demonstrate race condition, I wrote the following program. The program
has ten concurrent tasks that modify count, a volatile shared variable. If
I use the *increment* task (line 39), I get different results (like, e.g.
[2]) every time I run it, demonstrating the race condition.

However, if I use the *incrementStream* task instead (line 39), then the
count variable is not updated at all. The output is like [1] *every time*.
In a separate program not involving threads, I have verified that the
lambda expression like incrementStream updates a member variable as
expected.

What am I doing wrong?

Regards,
Kedar


public class RaceCondition {

    private static volatile int count = 0;
    public static void main(String[] args) {
        // update the shared variable traditionally
        Runnable increment = () -> {
            for (int i = 0; i < 1000; i++)
                count++;
        };
        // update the shared variable as a side effect of an
IntConsumer#accept
        Runnable incrementStream = () -> IntStream.rangeClosed(1,
100).forEach(i -> count++);
        ExecutorService exec = Executors.newCachedThreadPool(); // short
lived tasks
        try {
            for (int i = 0; i < 10; i++) {

​// ​
exec.execute(incrementStream)
​;
// line 38​
​​

              exec.execute(increment);
​         // line 39​

                System.out.println("task: " + i + " updates count to: " +
count);
            }
        } finally {
            exec.shutdown();
            System.out.println("final: " + count);
        }
    }

}
[1]
task: 0 updates count to: 0
task: 1 updates count to: 0
task: 2 updates count to: 0
task: 3 updates count to: 0
task: 4 updates count to: 0
task: 5 updates count to: 0
task: 6 updates count to: 0
task: 7 updates count to: 0
task: 8 updates count to: 0
task: 9 updates count to: 0
final: 0
[2]
task: 0 updates count to: 0
task: 1 updates count to: 1000
task: 2 updates count to: 1000
task: 3 updates count to: 2000
task: 4 updates count to: 4027
task: 5 updates count to: 5000
task: 6 updates count to: 6000
task: 7 updates count to: 7005
task: 8 updates count to: 8000
task: 9 updates count to: 8185
final: 9381
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170224/9ba84b49/attachment.html>


More information about the Concurrency-interest mailing list