On Sat, 05 Feb 2011 05:51:35 -0500, spir denis.s...@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
On Mon, 07 Feb 2011 07:48:53 -0500, Steven Schveighoffer
schvei...@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
On Fri, 04 Feb 2011 18:29:08 -0500, Sean Kelly s...@invisibleduck.org
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
On Mon, 07 Feb 2011 08:20:20 -0500, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Fri, 04 Feb 2011 18:29:08 -0500, Sean Kelly s...@invisibleduck.org
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
On Mon, 07 Feb 2011 10:33:29 -0500, Robert Jacques sandf...@jhu.edu
wrote:
On Mon, 07 Feb 2011 08:20:20 -0500, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Fri, 04 Feb 2011 18:29:08 -0500, Sean Kelly s...@invisibleduck.org
wrote:
On Feb 4, 2011, at 3:06 PM, Tomek Sowiński wrote:
Steven Schveighoffer Wrote:
On Fri, 04 Feb 2011 18:29:08 -0500, Sean Kelly s...@invisibleduck.org
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.
Steven Schveighoffer Wrote:
On Mon, 07 Feb 2011 10:33:29 -0500, Robert Jacques sandf...@jhu.edu
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
On Mon, 07 Feb 2011 14:29:37 -0500, Sean Kelly s...@invisibleduck.org
wrote:
Steven Schveighoffer Wrote:
On Mon, 07 Feb 2011 10:33:29 -0500, Robert Jacques sandf...@jhu.edu
wrote:
Steve, you can always assign to an object's monitor variable manually.
But adding this functionality to
Robert Jacques wrote:
On Fri, 04 Feb 2011 17:23:35 -0500, Jérôme M. Berger jeber...@free.fr
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
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
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
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
On Fri, 04 Feb 2011 07:26:22 -0500, bearophile bearophileh...@lycos.com
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
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
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
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)
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,
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?
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
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.
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
On Fri, 04 Feb 2011 17:23:35 -0500, Jérôme M. Berger jeber...@free.fr
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
On Fri, 04 Feb 2011 07:26:22 -0500, bearophile bearophileh...@lycos.com
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
On Fri, 04 Feb 2011 16:02:55 -0500, bearophile bearophileh...@lycos.com
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
On Fri, 04 Feb 2011 16:07:02 -0500, bearophile bearophileh...@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
25 matches
Mail list logo
