January 05, 2012 Re: Double Checked Locking | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | Andrei Alexandrescu wrote:
> only apply to portable C++2003 code
... and all
1) products derived from such code,
2) portable code in general, if similar argument chains can be
built up.
-manfred
| |||
January 05, 2012 Re: Double Checked Locking | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Manfred Nowak | This isn't strictly true because it would make implementing a mutex in C impossible. The more detailed answer is that the C/C++ (pre-0x) don't specify a way to do this, so it's compiler and platform-dependent.
Sent from my iPhone
On Jan 4, 2012, at 4:55 PM, Manfred Nowak <svv1999@hotmail.com> wrote:
> Sean Kelly wrote:
>
>> to ensure a correct result.
>
> According to Andrei's paper, there is no ensurance of a correct result possible. If optimizations reduce runtime, then not only MTBF will be reduced, but some problems might turn out to be incomputable on that "optimized machine". Nobody will know in advance which problems that are.
>
> Of course: this holds only if Andrei's conclusions in his paper are correct.
>
> -manfred
| |||
January 05, 2012 Re: Double Checked Locking | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Manfred Nowak | On 1/4/12 7:41 PM, Manfred Nowak wrote: > Andrei Alexandrescu wrote: > >> only apply to portable C++2003 code > > .... and all > > 1) products derived from such code, Yes. > 2) portable code in general, if similar argument chains can be > built up. No, because a language's specification can be refined to specify ordering in the presence of multiple threads. Andrei | |||
January 05, 2012 Re: Double Checked Locking | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | Andrei Alexandrescu wrote:
> specification can be refined
1) I do not see such refinements for D.
2) If there is _no_ requirement for such refinements to be used
"manually": which theory enables the compiler to detect the
prerequisites for the refinements automatically?
3) If there _is_ a requirement for such refinements to be used
"manually", then there is no such theory and your starting "No" turns
into a "Yes, of course, even if the specification _is_ refined, because
humans might fail".
-manfred
| |||
January 05, 2012 Re: Double Checked Locking | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Manfred Nowak | On 1/5/12 4:16 AM, Manfred Nowak wrote: > Andrei Alexandrescu wrote: > >> specification can be refined > > 1) I do not see such refinements for D. The shared qualifier is meant to guarantee sequential consistency. This is not yet implemented. > 2) If there is _no_ requirement for such refinements to be used > "manually": which theory enables the compiler to detect the > prerequisites for the refinements automatically? If I understand this correctly, you're asking whether races can be eliminated during compilation. Yes, it is possible, see a line of research started by Boyapati: http://eecs.umich.edu/~bchandra/publications/oopsla01.pdf. D is also designed to eliminate low-level races (in safe programs) during compilation because there is no undue aliasing. High-level races are not eliminated. > 3) If there _is_ a requirement for such refinements to be used > "manually", then there is no such theory and your starting "No" turns > into a "Yes, of course, even if the specification _is_ refined, because > humans might fail". I don't understand what this are trying to convey. Andrei | |||
Copyright © 1999-2021 by the D Language Foundation
Permalink
Reply