3 ms·

That seems like a bad thing. I'd think that you'd want your language to guarantee an initializer has completed before letting an object/structure/whatever be vi

• 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 ago
    Yes, 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.