A monitor for every object
I have found an interesting post by Scott Johnson in this Lambda the Ultimate thread: http://lambda-the-ultimate.org/node/724#comment-6621 He says: >9th circle: Concurrent mutable state. The obnoxious practice of mutating >shared state from multiple threads of control, leading into a predictable >cycle of race conditions, deadlocks, and other assorted misbehavior from which >there is no return. And if a correct solution (for synchronization) is found >for a given program, chances are any substantial change to the program will >make it incorrect again. But you won't find it, instead your customer will. >Despite that, reams of code (and TONS of middleware) has been written to try >and make this tractable. And don't get me started on a certain programming >language which starts with "J" that saw fit to make EVERY object have its very >own monitor< This is just one quotation, but I have found similar comments four or five other times around the Web. So is the design choice of copying this part of the Java design inside D good? I'd like opinions on this topic. Recently I have suggested an optional @nomonitor annotation for D classes (to optionally remove a word from class instances and to reduce class instantiation overhead a bit). Another option is doing the opposite, and defining a @withmonitor annotation where you want a class to have a monitor. Bye, bearophile
Re: A monitor for every object
Am 04.02.2011 13:26, schrieb bearophile: I have found an interesting post by Scott Johnson in this Lambda the Ultimate thread: http://lambda-the-ultimate.org/node/724#comment-6621 He says: 9th circle: Concurrent mutable state. The obnoxious practice of mutating shared state from multiple threads of control, leading into a predictable cycle of race conditions, deadlocks, and other assorted misbehavior from which there is no return. And if a correct solution (for synchronization) is found for a given program, chances are any substantial change to the program will make it incorrect again. But you won't find it, instead your customer will. Despite that, reams of code (and TONS of middleware) has been written to try and make this tractable. And don't get me started on a certain programming language which starts with "J" that saw fit to make EVERY object have its very own monitor< This is just one quotation, but I have found similar comments four or five other times around the Web. So is the design choice of copying this part of the Java design inside D good? I'd like opinions on this topic. Recently I have suggested an optional @nomonitor annotation for D classes (to optionally remove a word from class instances and to reduce class instantiation overhead a bit). Another option is doing the opposite, and defining a @withmonitor annotation where you want a class to have a monitor. Bye, bearophile Please note that D has a syntax for such things (optimizations with little behavior change). It called 'pragma'. Exchange @nomonitor with pragma(nomonitor) and I'm for your idea. pragma looks and feels better IMO. Mafi PS: cant see any @ttributes more :(
Re: A monitor for every object
On Fri, 04 Feb 2011 07:26:22 -0500, bearophile wrote: I have found an interesting post by Scott Johnson in this Lambda the Ultimate thread: http://lambda-the-ultimate.org/node/724#comment-6621 He says: 9th circle: Concurrent mutable state. The obnoxious practice of mutating shared state from multiple threads of control, leading into a predictable cycle of race conditions, deadlocks, and other assorted misbehavior from which there is no return. And if a correct solution (for synchronization) is found for a given program, chances are any substantial change to the program will make it incorrect again. But you won't find it, instead your customer will. Despite that, reams of code (and TONS of middleware) has been written to try and make this tractable. And don't get me started on a certain programming language which starts with "J" that saw fit to make EVERY object have its very own monitor< This is just one quotation, but I have found similar comments four or five other times around the Web. So is the design choice of copying this part of the Java design inside D good? I'd like opinions on this topic. Recently I have suggested an optional @nomonitor annotation for D classes (to optionally remove a word from class instances and to reduce class instantiation overhead a bit). Another option is doing the opposite, and defining a @withmonitor annotation where you want a class to have a monitor. D's monitors are lazily created, so there should be no issue with resource allocation. If you don't ever lock an object instance, it's not going to consume any resources. Most of the time the extra word isn't noticed because the memory size of a class is usually not exactly a power of 2. D also allows you to replace it's monitor with a custom monitor object (i.e. core.sync.Mutex) so you can have more control over the mutex, assign the same mutex to multiple objects, use conditions, etc. It's much more flexible than Java or C# IMO. -Steve
Re: A monitor for every object
bearophile Wrote: > a certain programming language which starts with "J" that saw fit to make > EVERY object have its very own monitor< > So is the design choice of copying this part of the Java design inside D > good? I'd like opinions on this topic. C# has this design too, but locking a common object directly is not used. C# used to create separate object for locking, the property to access it being called SyncRoot. It's implementation is a usual combination of new object() and CompareExchange. http://msdn.microsoft.com/en-us/library/system.collections.icollection.syncroot.aspx I don't feel the need for locking functionality in Object, this is usually a major design decision for a couple of classes - even in a large project. After all, after this design decision you should also carefully implement the locking in the code using the object, this will take some time, so it can't be a light-minded decision.
Re: A monitor for every object
Kagamin Wrote: > bearophile Wrote: > > > a certain programming language which starts with "J" that saw fit to make > > EVERY object have its very own monitor< > > So is the design choice of copying this part of the Java design inside D > > good? I'd like opinions on this topic. > > C# has this design too, but locking a common object directly is not used. C# > used to create separate object for locking, the property to access it being > called SyncRoot. It's implementation is a usual combination of new object() > and CompareExchange. Ah, I forgot to say, that C# has a sort of guideline to lock the SyncRoot instead of collection itself.
Re: A monitor for every object
Steven Schveighoffer: > D's monitors are lazily created, so there should be no issue with resource > allocation. If you don't ever lock an object instance, it's not going to > consume any resources. One more thing. I remember working with LDC some developers to speed up the stack (scope) allocation of class instances (in D1), and I remember one of the slows down comes from the need to call something that sets the monitor pointer. This call to the runtime was never inlined by ldc, so it was a significant cost compared to similar class instances stack allocated by the JavaVM through escape analysis. So moniror management has a cost in LDC and I presume in DMD too, unless some inlining here will be somehow forced. Bye, bearophile
Re: A monitor for every object
Steven Schveighoffer: > Most of the time the extra word isn't noticed > because the memory size of a class is usually not exactly a power of 2. I'd like to know in a normal object oriented program how much memory this design actually wastes. Thank you to you and Kagamin for your answers, bye, bearophile
Re: A monitor for every object
Steven Schveighoffer wrote: > D's monitors are lazily created, so there should be no issue with > resource allocation. What happens if two threads attempt to create a monitor for the same object at the same time? Is there a global lock to avoid race conditions in this case? Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: A monitor for every object
Steven Schveighoffer napisał: > D's monitors are lazily created, so there should be no issue with resource > allocation. If you don't ever lock an object instance, it's not going to > consume any resources. Most of the time the extra word isn't noticed > because the memory size of a class is usually not exactly a power of 2. Except when you put'em in an array. Could happen. > D also allows you to replace it's monitor with a custom monitor object > (i.e. core.sync.Mutex) so you can have more control over the mutex, assign > the same mutex to multiple objects, use conditions, etc. It's much more > flexible than Java or C# IMO. I didn't know, thx. Where is it documented? -- Tomek
Re: A monitor for every object
On Feb 4, 2011, at 3:06 PM, Tomek Sowiński wrote: > Steven Schveighoffer napisał: > >> D also allows you to replace it's monitor with a custom monitor object >> (i.e. core.sync.Mutex) so you can have more control over the mutex, assign >> the same mutex to multiple objects, use conditions, etc. It's much more >> flexible than Java or C# IMO. > > I didn't know, thx. Where is it documented? Only in the docs for the Mutex ctor here: http://www.digitalmars.com/d/2.0/phobos/core_sync_mutex.html By the way, when using Mutex as an object monitor you currently can't attach dispose event handlers to the object (ie. via std.signals). That functionality is only supported by the default monitor. I've considered changing this, but doing so imposes some weird requirements on the creators of an external object monitor, like Mutex.
Re: A monitor for every object
Tomek Sowiński napisał: > > D's monitors are lazily created, so there should be no issue with resource > > allocation. If you don't ever lock an object instance, it's not going to > > consume any resources. Most of the time the extra word isn't noticed > > because the memory size of a class is usually not exactly a power of 2. > > Except when you put'em in an array. Could happen. Sorry, for some reason I thought the mutex is on the stack. -- Tomek
Re: A monitor for every object
On Fri, 04 Feb 2011 17:23:35 -0500, Jérôme M. Berger wrote: Steven Schveighoffer wrote: D's monitors are lazily created, so there should be no issue with resource allocation. What happens if two threads attempt to create a monitor for the same object at the same time? Is there a global lock to avoid race conditions in this case? Jerome Only the reference to the mutex is shared, so all you need in an atomic op.
Re: A monitor for every object
On Fri, 04 Feb 2011 07:26:22 -0500, bearophile wrote: I have found an interesting post by Scott Johnson in this Lambda the Ultimate thread: http://lambda-the-ultimate.org/node/724#comment-6621 He says: 9th circle: Concurrent mutable state. The obnoxious practice of mutating shared state from multiple threads of control, leading into a predictable cycle of race conditions, deadlocks, and other assorted misbehavior from which there is no return. And if a correct solution (for synchronization) is found for a given program, chances are any substantial change to the program will make it incorrect again. But you won't find it, instead your customer will. Despite that, reams of code (and TONS of middleware) has been written to try and make this tractable. And don't get me started on a certain programming language which starts with "J" that saw fit to make EVERY object have its very own monitor< This is just one quotation, but I have found similar comments four or five other times around the Web. So is the design choice of copying this part of the Java design inside D good? I'd like opinions on this topic. Recently I have suggested an optional @nomonitor annotation for D classes (to optionally remove a word from class instances and to reduce class instantiation overhead a bit). Another option is doing the opposite, and defining a @withmonitor annotation where you want a class to have a monitor. Hmm... Well, I'd recommend making @nomonitor the default and then only annotate certain classes @withmonitor, although I'd prefer a different keyword, say 'shared'. Oh, wait a second. *sigh* Every since it was decided that a class couldn't contain both shared and non-shared methods/fields I've been expecting that the monitor and support for synchronized methods would be removed from Object or at least from Object's spec. But this is likely a high-cost/low-gain optimization and a lot of things regarding shared/immutable classes need to be fixed before it can happen. I do think it should happen, not so much for the word of memory, but in order to prevent objects not designed to be shared from being shared. Which is what the 9th circle is talking about. One of the cool thing about D's monitors, is that by manually setting them, you can protect multiple objects with a single monitor. So, for a set of interwoven objects (i.e. trees, etc) you're not acquiring a new lock every method call and you are not going to have an internal deadlock/race. This is actually the essential runtime feature of many ownership systems. (Although, without an actual ownership-type system you can't elide synchronization entirely)
Re: A monitor for every object
On Fri, 04 Feb 2011 16:02:55 -0500, bearophile wrote: Steven Schveighoffer: Most of the time the extra word isn't noticed because the memory size of a class is usually not exactly a power of 2. I'd like to know in a normal object oriented program how much memory this design actually wastes. Thank you to you and Kagamin for your answers, bye, bearophile 1 word per object, assuming a uniform distribution of object sizes. Yes, _most_ objects aren't affected, but the ones that are make up for the difference by using twice the ram.
Re: A monitor for every object
On Fri, 04 Feb 2011 16:07:02 -0500, bearophile wrote: Steven Schveighoffer: D's monitors are lazily created, so there should be no issue with resource allocation. If you don't ever lock an object instance, it's not going to consume any resources. One more thing. I remember working with LDC some developers to speed up the stack (scope) allocation of class instances (in D1), and I remember one of the slows down comes from the need to call something that sets the monitor pointer. This call to the runtime was never inlined by ldc, so it was a significant cost compared to similar class instances stack allocated by the JavaVM through escape analysis. So moniror management has a cost in LDC and I presume in DMD too, unless some inlining here will be somehow forced. Bye, bearophile Well, in DMD the monitor is null prior to use, so I'm not sure what's happening in LDC, but I'd doubt DMD is making such a call just to set it to 0.
Re: A monitor for every object
Robert Jacques wrote: > On Fri, 04 Feb 2011 17:23:35 -0500, Jérôme M. Berger > wrote: > >> Steven Schveighoffer wrote: >>> D's monitors are lazily created, so there should be no issue with >>> resource allocation. >> What happens if two threads attempt to create a monitor for the >> same object at the same time? Is there a global lock to avoid race >> conditions in this case? >> >> Jerome > > Only the reference to the mutex is shared, so all you need in an atomic op. This requires an atomic "if (a is null) a = b;". I did not know that such a beast existed. Jerome -- mailto:jeber...@free.fr http://jeberger.free.fr Jabber: jeber...@jabber.fr signature.asc Description: OpenPGP digital signature
Re: A monitor for every object
Steven Schveighoffer: D's monitors are lazily created, so there should be no issue with resource allocation. If you don't ever lock an object instance, it's not going to consume any resources. For the non-sorcerers following the thread, would someone explain in a few words what it actually means, conceptually and concretely, for an object to be its own monitor. (searches online have brought me nothing relevant) Denis -- _ vita es estrany spir.wikidot.com
Re: A monitor for every object
On Sat, 05 Feb 2011 03:00:31 -0500, Jérôme M. Berger wrote: Robert Jacques wrote: On Fri, 04 Feb 2011 17:23:35 -0500, Jérôme M. Berger wrote: Steven Schveighoffer wrote: D's monitors are lazily created, so there should be no issue with resource allocation. What happens if two threads attempt to create a monitor for the same object at the same time? Is there a global lock to avoid race conditions in this case? Jerome Only the reference to the mutex is shared, so all you need in an atomic op. This requires an atomic "if (a is null) a = b;". I did not know that such a beast existed. Jerome Yes, the beast exists and it's the basis for most lock-free programming as well as lock implementations. It's generally known as compare and swap or CAS (see http://en.wikipedia.org/wiki/Compare_and_swap and core.atomic.cas). There's also another atomic primitive called Load-Link/Store-Conditional, which is available an several non-x86 architectures (ARM, PowerPC, etc) and is generally considered a more powerful primitive than CAS.
Re: A monitor for every object
On Sat, 05 Feb 2011 05:51:35 -0500, spir wrote:
Steven Schveighoffer:
D's monitors are lazily created, so there should be no issue with
resource
allocation. If you don't ever lock an object instance, it's not going
to
consume any resources.
For the non-sorcerers following the thread, would someone explain in a
few words what it actually means, conceptually and concretely, for an
object to be its own monitor. (searches online have brought me nothing
relevant)
A monitor is used for concurrency. Essentially, it is a mutex (or
critical section on Windows). When you do this:
class C
{
synchronized void foo() {}
}
The synchronized keyword means a call to foo will lock the embedded
monitor before calling it.
The meaning of an 'object being its own monitor' is just that the monitor
for operations on an object is conceptually the object itself (even though
it's technically a hidden member of the object).
This model has some very bad drawbacks, because it encourages you to use
an object to lock an operation on itself when most cases, you want more
coarse mutexes (mutexes should be tied to entire concepts, not just to
individual objects).
With D, you can alleviate this somewhat by specifying a specific monitor
for an object.
To explain my statement in real-world terms, the monitor is essentially a
resource handle (on linux, this is a pthread_mutext_t) that begins life as
null. When an object is locked for the very first time, some low-level
atomic code checks to see if the monitor is allocated and if not, creates
a pthread mutex and assigns it to that hidden monitor field.
Once the monitor is created, it's used from now on. What I meant by lazy
creation is that simply creating an object doesn't also consume a mutex
resource + degrade performance. It's only on the first lock that you have
to worry about it.
-Steve
Re: A monitor for every object
On Mon, 07 Feb 2011 07:48:53 -0500, Steven Schveighoffer wrote: The meaning of an 'object being its own monitor' is just that the monitor for operations on an object is conceptually the object itself (even though it's technically a hidden member of the object). This model has some very bad drawbacks, because it encourages you to use an object to lock an operation on itself when most cases, you want more coarse mutexes (mutexes should be tied to entire concepts, not just to individual objects). With D, you can alleviate this somewhat by specifying a specific monitor for an object. I may be wrong on this one, it looks like from the docs a mutex can only be assigned to exactly one object. But I've asked Sean to clarify. -Steve
Re: A monitor for every object
On Fri, 04 Feb 2011 18:29:08 -0500, Sean Kelly wrote: On Feb 4, 2011, at 3:06 PM, Tomek Sowiński wrote: Steven Schveighoffer napisał: D also allows you to replace it's monitor with a custom monitor object (i.e. core.sync.Mutex) so you can have more control over the mutex, assign the same mutex to multiple objects, use conditions, etc. It's much more flexible than Java or C# IMO. I didn't know, thx. Where is it documented? Only in the docs for the Mutex ctor here: http://www.digitalmars.com/d/2.0/phobos/core_sync_mutex.html By the way, when using Mutex as an object monitor you currently can't attach dispose event handlers to the object (ie. via std.signals). That functionality is only supported by the default monitor. I've considered changing this, but doing so imposes some weird requirements on the creators of an external object monitor, like Mutex. Sean, I could have sworn that mutex can take over multiple objects' monitors. This would be highly desirable in a complex structure where members of an object should use the same mutex for synchronized calls. But looking at the docs once again, it looks like it can only be the monitor for one object (as the target object is accepted only on construction). Is that a limitation we cannot remove? -Steve
Re: A monitor for every object
On Mon, 07 Feb 2011 08:20:20 -0500, Steven Schveighoffer wrote: On Fri, 04 Feb 2011 18:29:08 -0500, Sean Kelly wrote: On Feb 4, 2011, at 3:06 PM, Tomek Sowiński wrote: Steven Schveighoffer napisał: D also allows you to replace it's monitor with a custom monitor object (i.e. core.sync.Mutex) so you can have more control over the mutex, assign the same mutex to multiple objects, use conditions, etc. It's much more flexible than Java or C# IMO. I didn't know, thx. Where is it documented? Only in the docs for the Mutex ctor here: http://www.digitalmars.com/d/2.0/phobos/core_sync_mutex.html By the way, when using Mutex as an object monitor you currently can't attach dispose event handlers to the object (ie. via std.signals). That functionality is only supported by the default monitor. I've considered changing this, but doing so imposes some weird requirements on the creators of an external object monitor, like Mutex. Sean, I could have sworn that mutex can take over multiple objects' monitors. This would be highly desirable in a complex structure where members of an object should use the same mutex for synchronized calls. But looking at the docs once again, it looks like it can only be the monitor for one object (as the target object is accepted only on construction). Is that a limitation we cannot remove? -Steve Steve, you can always assign to an object's monitor variable manually. But adding this functionality to Mutex's and Object's API would be appreciated.
Re: A monitor for every object
On Mon, 07 Feb 2011 10:33:29 -0500, Robert Jacques wrote: On Mon, 07 Feb 2011 08:20:20 -0500, Steven Schveighoffer wrote: On Fri, 04 Feb 2011 18:29:08 -0500, Sean Kelly wrote: On Feb 4, 2011, at 3:06 PM, Tomek Sowiński wrote: Steven Schveighoffer napisał: D also allows you to replace it's monitor with a custom monitor object (i.e. core.sync.Mutex) so you can have more control over the mutex, assign the same mutex to multiple objects, use conditions, etc. It's much more flexible than Java or C# IMO. I didn't know, thx. Where is it documented? Only in the docs for the Mutex ctor here: http://www.digitalmars.com/d/2.0/phobos/core_sync_mutex.html By the way, when using Mutex as an object monitor you currently can't attach dispose event handlers to the object (ie. via std.signals). That functionality is only supported by the default monitor. I've considered changing this, but doing so imposes some weird requirements on the creators of an external object monitor, like Mutex. Sean, I could have sworn that mutex can take over multiple objects' monitors. This would be highly desirable in a complex structure where members of an object should use the same mutex for synchronized calls. But looking at the docs once again, it looks like it can only be the monitor for one object (as the target object is accepted only on construction). Is that a limitation we cannot remove? -Steve Steve, you can always assign to an object's monitor variable manually. But adding this functionality to Mutex's and Object's API would be appreciated. Sure, Mutex does this already. What I was simply asking is if it will blow up or not :) -Steve
Re: A monitor for every object
Steven Schveighoffer Wrote: > On Fri, 04 Feb 2011 18:29:08 -0500, Sean Kelly > wrote: > > > On Feb 4, 2011, at 3:06 PM, Tomek SowiÅski wrote: > > > >> Steven Schveighoffer napisaÅ: > >> > >>> D also allows you to replace it's monitor with a custom monitor object > >>> (i.e. core.sync.Mutex) so you can have more control over the mutex, > >>> assign > >>> the same mutex to multiple objects, use conditions, etc. It's much > >>> more > >>> flexible than Java or C# IMO. > >> > >> I didn't know, thx. Where is it documented? > > > > Only in the docs for the Mutex ctor here: > > > > http://www.digitalmars.com/d/2.0/phobos/core_sync_mutex.html > > > > By the way, when using Mutex as an object monitor you currently can't > > attach dispose event handlers to the object (ie. via std.signals). That > > functionality is only supported by the default monitor. I've considered > > changing this, but doing so imposes some weird requirements on the > > creators of an external object monitor, like Mutex. > > Sean, I could have sworn that mutex can take over multiple objects' > monitors. This would be highly desirable in a complex structure where > members of an object should use the same mutex for synchronized calls. > > But looking at the docs once again, it looks like it can only be the > monitor for one object (as the target object is accepted only on > construction). Is that a limitation we cannot remove? Now that you mention it, I think TDPL describes a call like setMonitor() that's supposed to do this, and I just forgot to implement it. There's no technical barrier. It's simply a matter of assigning the monitor reference to the correct part of the Mutex instance.
Re: A monitor for every object
Steven Schveighoffer Wrote: > On Mon, 07 Feb 2011 10:33:29 -0500, Robert Jacques > wrote: > > > > Steve, you can always assign to an object's monitor variable manually. > > But adding this functionality to Mutex's and Object's API would be > > appreciated. > > Sure, Mutex does this already. What I was simply asking is if it will > blow up or not :) It'll work fine, so long as the monitor is a Mutex. If you want to share the default monitor, that will require some work, because the instance is manually allocated. Oh, another issue with using Mutex as an object monitor is that it's allocated on the GC heap, so a synchronized block in the object's dtor could fail. All the usual workarounds apply--just something to be aware of.
Re: A monitor for every object
On Mon, 07 Feb 2011 14:29:37 -0500, Sean Kelly wrote: Steven Schveighoffer Wrote: On Mon, 07 Feb 2011 10:33:29 -0500, Robert Jacques wrote: > > Steve, you can always assign to an object's monitor variable manually. > But adding this functionality to Mutex's and Object's API would be > appreciated. Sure, Mutex does this already. What I was simply asking is if it will blow up or not :) It'll work fine, so long as the monitor is a Mutex. If you want to share the default monitor, that will require some work, because the instance is manually allocated. I think sharing a default monitor is not necessary, we can make do with Mutex. Oh, another issue with using Mutex as an object monitor is that it's allocated on the GC heap, so a synchronized block in the object's dtor could fail. All the usual workarounds apply--just something to be aware of. It might be a good idea to identify these limitations (the signal one and this one) in the docs if they aren't already... And thanks for looking at this. -Steve
