From: Joel VanderWerf Date: 2006-05-23T03:20:30+09:00 Subject: Re: sysread changes behavior in the presence of threads? Francis Cianfrocca wrote: > We're threadjacking, so I'll keep it short. The point of taking a very I like this thread, but I'll nudge it in the ruby direction... > restrictive view of synchronization is to prevent incorrect concurrency. > Your example depends on the implementation of aMap and of calculateValue > not > to do evil things. (One of the evil things they can do is simply to run for > several milliseconds, or make a blocking I/O call. This can give you a bad > case of mutex contention, which is exceptionally costly in many modern > implementations.) This means that the program may change behavior with > respect to concurrency across platforms, hardware, and also across time (as > the code inside those called functions changes). Ruby adds the further > dimension that the code you call under lock may have been metaprogrammed on > the fly. If you're talking about ruby threads, sync mechanisms are expensive with or without contention, since they are built on top of Thread.critical. require 'thread' require 'benchmark' N = 1_000_000 Benchmark.bmbm(12) do |bm| bm.report("no Thread.critical") do x = 0 N.times do x += 1 end end bm.report("Thread.critical") do x = 0 N.times do Thread.critical = true x += 1 Thread.critical = false end end bm.report("Thread.exclusive") do x = 0 N.times do Thread.exclusive do x += 1 end end end end __END__ Rehearsal ------------------------------------------------------ no Thread.critical 1.040000 0.010000 1.050000 ( 1.063126) Thread.critical 1.130000 0.000000 1.130000 ( 1.153935) Thread.exclusive 2.660000 0.000000 2.660000 ( 2.704054) --------------------------------------------- total: 4.840000sec user system total real no Thread.critical 0.360000 0.000000 0.360000 ( 0.366529) Thread.critical 0.910000 0.010000 0.920000 ( 0.922671) Thread.exclusive 2.670000 0.000000 2.670000 ( 2.692268) -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407