3 ms·
It's a performance trade off, because in general it's hard for the compiler to know whether it needs to insert a memory barrier or not if you do something like:
by johncolanduoni 9y ago
It's a performance trade off, because in general it's hard for the compiler to know whether it needs to insert a memory barrier or not if you do something like:
this.fooField = new Something()
which would need a memory barrier if another thread is expected to access fooField concurrently, and not need one otherwise. Putting memory barriers on every field assignment of a constructed object would be pretty expensive.
It's also worth noting there's not anything that special about constructors here; there's a million other ways you can get similar issues when you try to handle concurrency at this level. For example if you do:
this.bar.changeSomeFields()
this.fooField = this.bar
and changeSomeFields doesn't invoke a memory barrier at the right time you'll get the same problem if fooField isn't volatile.
- jmull 9y agoYes, I guess it is reasonable. Come to think of it, I objected because I thought it doesn't give you a chance to initialize whatever your object/structure/whatever's synchronization mechanism is. But that's not really true. The call to initialize your synchronization mechanism would contain the barrier you need so a general initialization doesn't generally need one.