headers
rfo | 25 Jul 2012 14:57

RE: [eiffel_software] yavsa

Hi Marco

Yup.  I forgot about the attribute rule :(

That said, and I know my compiler writer credentials are not as
impressive as some, it seems to me that in a single threaded system
(which this is; I just double checked), that such a limitation is
irrelvant and should be relaxed.  It's a clear basic block, with no
address aliasing possible, and as close to atomic as one can get in a
very high level language.
I understand that the code doesn't know whether it's in a threaded
environment or not, so it might be better to make the offense a warning
when single threaded and a hard error when multithreaded (and make the
warning/error message more precise rather than a catch-all).

Thanks

R

==================================================
Roger F. Osmond

 

-------- Original Message --------
Subject: Re: [eiffel_software] yavsa
From: Marco Trudel <marco@...>
Date: Wed, July 25, 2012 8:33 am
To: eiffel_software@...
(Continue reading)

Permalink | Reply |
headers
Marco Trudel | 25 Jul 2012 15:06
Picon

Re: yavsa

So you're suggesting that the compiler accepts:

    xyz: LINKED_LIST [INTEGER_32]
    b: LINKED_LIST [INTEGER_32]
    foo (other: like Current)
       do
          if attached xyz as a then
             create b.make
             b.fill (a)
          end
       end

And if the programmer changes foo to e.g.

    foo (other: like Current)
       do
          if attached xyz as a then
             create b.make
             other.b := Void <-- new line, rest untouched
             b.fill (a)
          end
       end

a compiler error about "b.fill (a)" is reported?

Marco

On 25.07.2012 14:57, rfo@... wrote:
> Hi Marco
>
(Continue reading)

Permalink | Reply |
headers
rfo | 25 Jul 2012 15:22

RE: [eiffel_software] yavsa

Hi Marco

Actually, yes, in a multithreaded system but I'd be even fussier than
that.  Another thread can make a change in between instructions, even
without the intervening call in your example.  That I believe is the
motivation for the attribute rule.
The attachment test block is not AS susceptible to the same issue.  The
autogenerated local is a valid handle to a non-void object, so even if
the original attribute gets nuked by another thread, the automatic
handle keeps the object alive within the if block.  The original
attribute is just another handle to an object, not an object itself.  At
least that's the idea.
The attachment test safety can be absolutely true ONLY if the generated
code of the attachment test is effectively atomic w/r/t threading.  I
certainly hope it is.

R

==================================================
Roger F. Osmond

 

-------- Original Message --------
Subject: Re: [eiffel_software] yavsa
From: Marco Trudel <marco@...>
Date: Wed, July 25, 2012 9:06 am
To: eiffel_software@...

  So you're suggesting that the compiler accepts:
(Continue reading)

Permalink | Reply |
headers
Marco Trudel | 25 Jul 2012 15:32
Picon

Re: yavsa

I'm now confused about discussing single and multithreaded at the same 
time. So let's just drop the multithreaded for the example. After doing 
that (in single-threaded mode):

|_ foo (other: like Current)
|___ do
|_____ if attached xyz as a then
|_______ create b.make
|_______ other.b := Void <-- you added this line
|_______ -- other code in between
|_______ b.fill (a)
|_____ end
|___ end

You would be fine with the compiler all the sudden reporting a void 
error in a completely unrelated location of what you just added? Even 
though your added code is perfectly fine?
Sorry if this is the same question as before, but I didn't quite 
understand your answer.

Cheers!
Marco

On 25.07.2012 15:22, rfo@... wrote:
> Hi Marco
>
> Actually, yes, in a multithreaded system but I'd be even fussier than
> that. Another thread can make a change in between instructions, even
> without the intervening call in your example. That I believe is the
> motivation for the attribute rule.
(Continue reading)

Permalink | Reply |
headers
rfo | 25 Jul 2012 16:08

RE: [eiffel_software] yavsa

Hi Marco

Taking the single threaded case, any intervening call (other than the
form b.x because that keeps the handle 'b' in play) can have the effect
of Voiding the handle 'b'. Without the intervening call, this cannot
happen in the single threaded case.

1 - create b.make -- b is now non-Void and the object to which it refers
can be accessed
2 - a := b.something -- is going to be OK and cannot Void b (handle 'b'
remains in scope)
3 - c.something -- has potential of Voiding b, so terminates the basic
block
4 - b.something -- is NOT going to be OK because is outside of safe
block

In a multithreaded system, it's worse.

1 - create b.make -- b is now non-void
2 - a := b.something -- Not OK because another thread could have Voided
b between instructions 1 and 2

 
The attachment test creates a safe block

1 - create b.make
2 - if attached b as ba then
3 ---  ba.something  -- OK because object access is via 'ba', a
temporary handle, in scope
4 - end
(Continue reading)

Permalink | Reply |

Gmane