Michel Fortin wrote:
> Le 2010-02-10 ? 16:54, Andrei Alexandrescu a ?crit :
> 
>>> Are you saying you cannot access public members of a thread-unware object? This would lead to a race in this situation.
>> You can, but they're qualified with shared, just the same way the synchronized method sees them. There is no race. I'm sure there is a misunderstanding somewhere.
> 
> I agree there is no race as long as you don't put a cast in there.

OK, great. I mean whew!

> If
> you go back a few emails, you'll note that I was talking about the
> context where you want to have something owned beyond an indirection.
> In this situation the compiler is more than unhelpful since not only
> you need a cast (but I digest), it also allows you to escape your
> "owned beyond an indirection" data without a cast.
> 
> I'm saying that this will be a common enough case that it should be better. If it wasn't a common enough case you wouldn't have that "cast away shared" chapter. So in that common enough case that require a cast you'll not only need a cast, but you'll also need to be extra cautious about what escapes even in functions that do not have a cast.
> 
> So I was simply suggesting that the compiler helps by knowing up to what level of indirection the data is "owned". For instance, by my suggestion, this:
> 
> synchronized class A { int[] x; shared(int)[] y; }
> 
> has member x is owned entirely (including the referenced data) by the
> object while for member y only the head (or tail? I'm always mixing
> those terms) is owned. This means you can't take the address of x's
> content (just like you can't take the address of x or y). Well, you
> can, but you need a cast.

I see; good idea. So everything not marked explicitly as shared, at any level, would be considered owned and can't escape. Beyond a point, the switch is turned and stuff becomes shared, and so can escape no problem.

I'll talk to Walter about what it takes to implement this.

This scheme only works for arrays and pointers, but they are frequent enough to warrant such a rule. Classes remain the way they are - they have to fend for themselves.

Thanks! This is a great idea.


Andrei

S2.16: "Also, some processor offered more advanced light weight interlocked instructions such as atomic increment or test-and-set.": some processor => some processors

Question: will cas also support 2-word structs and/or smaller types like shorts and bytes?

S 2.16.2: This section should mention the ABA problem, the common solution (tagging) and note it doesn't always work due to overflow.

P.S. Given all I've read, lock-free programming is more like the Olympics than the Iron Man :)

Le 2010-02-10 ? 18:02, Andrei Alexandrescu a ?crit :

> I see; good idea. So everything not marked explicitly as shared, at any level, would be considered owned and can't escape. Beyond a point, the switch is turned and stuff becomes shared, and so can escape no problem.

Exactly.


> I'll talk to Walter about what it takes to implement this.
> 
> This scheme only works for arrays and pointers, but they are frequent enough to warrant such a rule. Classes remain the way they are - they have to fend for themselves.


If I'm not mistaken access to struct and class fields behind an indirection should be safe too if you access them directly from the synchronized method. As long as you don't need to pass the reference to a function it should be safe and not require a cast.


> Thanks! This is a great idea.


You're welcome. I'm glad you like it. :-)

Note that you have to be careful about assignments too. Say you have "int* x": since the integer is owned the compiler should not allow assignment "x = something;" because you could end up assigning something that someone else has a reference to; a pre-leaked reference if you want. So assignment to "x" would require a cast. There could be an exception for "x = new int;", but for struct and classes it works only when you're not using a constructor that leaks a reference.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

2.16.1

"use the shared attribute", but the LockFreeStruct and LockFreeClass don't have the shared attribute.

Thanks!

Andrei

Walter Bright wrote:
> 2.16.1
> 
> "use the shared attribute", but the LockFreeStruct and LockFreeClass
> don't have the shared attribute.
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency

2.13
// C++ version of an interlocked bank account
class BankAccound {

Usage of "auto" in the "C++" code example looks confusing at least; strictly speaking "auto lock =" actually means that lock has type int.

2.14 page 69 "Array fields declared declared with type T[]...", looks like a typo

On Fri, Feb 12, 2010 at 11:55 PM, Igor Lesik <curoles at yahoo.com> wrote:
> strictly speaking "auto lock =" actually means that lock has type int.
>
>

Strictly speaking, it also lacks semicolon after struct definition :)

Le 2010-02-12 ? 15:55, Igor Lesik a ?crit :

> 2.13
> // C++ version of an interlocked bank account
> class BankAccound {
> 
> Usage of "auto" in the "C++" code example looks confusing at least; strictly speaking "auto lock =" actually means that lock has type int.

Andrei is just anticipating C++0x will be official before his book. :-)

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/

a) Is std.concurrency available in any form?

b) Does 2.040 support synchronized classes?
Following code:
synchronized class WhereIsThe {
??? private int fun = 2;
}
gives Error: variable test4.WhereIsThe.fun variable fun cannot be synchronized