Re: Concurrency and delegates

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

Peter Duniho <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote:
One technique I've seen suggested doesn't use locking at all. It just
copies the event. I'm not really clear on why that's considered
thread-safe (it doesn't seem to me that it would be),

It's thread safe in that it won't throw a NullReferenceException.
However, it won't necessarily use the latest value of the variable
unless there are memory barriers in place.

So, copying the event instance is an atomic operation? Is that because
there's some behind-the-scenes locking going on? Or is it because the
event can be copied in a single CPU-atomic operation?

Reference assignments are always atomic - that's guaranteed under all
the memory models I've seen.

I believe the consensus is that under the MS CLR 2.0 memory model,
it's safe - but it's not *strictly speaking* safe under ECMA.

So what are the chances it could change in the future? Is this
something that people should be cautioned to avoid relying on? Or is
this one of those things that so much code would break if Microsoft
changes the model that they would never change it in a way that would
break this?

The latter - the situation suggested is basically insane. If you can't
rely on local variables being "safe" then life becomes impossible.

that's a long way of saying that I think the last example you posted is
in fact the close to the recommended practice for thread-safe
event-raising. The only discrepancy would be the use of "this" as
opposed to a dedicated object instance for locking.

And holding the lock while calling the other code - a definite "no-
no".

Well, the last example in Scott's post didn't have that problem. :)

Indeed - somehow I'd missed that.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: Exploiting Dual Cores with Py_NewInterpreters separated GIL ?
    ... sufficient to make reference counting safe." ... using atomic inc/dec is as thread-safe as a non-COW String implementation ... About the term "thread-safe". ...
    (comp.lang.python)
  • Re: Concurrency and delegates
    ... Is that because there's some behind-the-scenes locking going on? ... Or is it because the event can be copied in a single CPU-atomic operation? ... it's safe - but it's not *strictly speaking* safe under ECMA. ... in fact the close to the recommended practice for thread-safe ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: setting timer
    ... >> here copied below for your convenience. ... This definition of safe has a particular meaning, ... then it is safe". ...
    (comp.unix.programmer)
  • Re: Thread-safe assignments
    ... I realize that my recent question about thread-safe caches was pretty ... Is it safe to assume that the reading threads will only ever read the ... More precisely, instructions themselves tend to be atomic, ...
    (comp.lang.lisp)