Re: int number = new int();

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Peter Duniho <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote:
[...]
However, it can occasionally be an interesting way of thinking about
other aspects of behaviour. It's easy enough to see that if data is to
be shared between threads, it has to be on the heap - and conversely,
that if data is only on the stack, it's threadsafe. (Assuming no
*really* nasty hacks, admittedly.)

Well, that's interesting.

I'm still not sure I'd go around assuming that data on the stack is
threadsafe, but until you wrote the above, I had no idea that you weren't
allowed to use by-reference arguments in anonymous methods.

You can:

using System;

class Test
{
delegate void Foo(ref int i);

public static void Main()
{
Foo f = delegate (ref int x) { x = 10; };

int j = 0;
f(ref j);
Console.WriteLine(j);
}
}

Not sure what you meant, but the thread-safe aspect seems sensible to
me - if the data is on the stack, how can another thread get at it?
Note that I'm talking about the *actual data* here - if you happen to
have a reference to an object, then of course a different thread may be
able to modify that object's data if it's got a reference to it.

As for "*really* nasty hacks" go, I guess that depends on your
definition. All that's really necessary in order to get stack-stored data
from one thread to another is the use of unsafe code (i.e. pointers).
It's not like you have to write self-modifying code, or generate your own
IL, or otherwise do an end-around of the compiler.

Unsafe code at both sides (I suspect) - which means it would at least
be deliberate.

I'm of the general opinion that any use of unsafe code could be considered
"nasty", but I have to admit that not everyone agrees. And personally, I
think maybe unsafe code is simply "nasty", not necessarily "*really*
nasty".

So, what's _your_ definition of "*really* nasty hacks"? I assume it
includes the use of unsafe code. :)

Not necessarily - but anything which is deliberately making stack data
available to a different thread is really nasty (and brittle) IMO.

--
Jon Skeet - <skeet@xxxxxxxxx>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
.

Relevant Pages

  • Re: int number = new int();
    ... allowed to use by-reference arguments in anonymous methods. ... delegate void Foo(ref int i); ... it prohibits the one dangerous use case I can think of that might have led to access to stack data for one thread from another. ... using unsafe code, simply by passing a pointer instead of a by-ref argument. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: int number = new int();
    ... I'm still not sure I'd go around assuming that data on the stack is threadsafe, but until you wrote the above, I had no idea that you weren't allowed to use by-reference arguments in anonymous methods. ... As for "*really* nasty hacks" go, I guess that depends on your definition. ... All that's really necessary in order to get stack-stored data from one thread to another is the use of unsafe code. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: linux interrupt handler/bottom half
    ... > grep the sources for that (in a PowerPC distribution) I think you'll find ... have a usable stack. ... There are lot of nasty things user mode code could ... corrupt, which will give you a good chance of a fast ...
    (comp.os.linux.development.system)
  • Re: Global labels in inline assembly.
    ... prepared to deal with all the stack issues and other nasty stuff ... does a lot of bizarre stack manipulations and I'm prepared for all ... and am able to declare public global labels that allow me to do each ...
    (alt.lang.asm)
  • Compress stack unwinder output
    ... The unwinder has some extra newlines, which eat up loads of screen ... for a nasty example). ... if (!stack) { ... unsigned long dummy; ...
    (Linux-Kernel)