• bearophile <bearophileHUGS lycos.com> Feb 04 2011
• "Robert Jacques" <sandford jhu.edu> Feb 04 2011
• spir <denis.spir gmail.com> Feb 05 2011
• "Steven Schveighoffer" <schveiguy yahoo.com> Feb 07 2011
• "Steven Schveighoffer" <schveiguy yahoo.com> Feb 07 2011

bearophile <bearophileHUGS lycos.com> writes:

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

"Robert Jacques" <sandford jhu.edu> writes:

On Fri, 04 Feb 2011 16:07:02 -0500, bearophile <bearophileHUGS lycos.com>  
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.

spir <denis.spir gmail.com> writes:

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

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Sat, 05 Feb 2011 05:51:35 -0500, spir <denis.spir gmail.com> 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

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Mon, 07 Feb 2011 07:48:53 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> 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