Andrew Russell

Brisbane, Australia

andrewrussell.net

Hi! I am Andrew Russell. I'm an indie game developer from Australia. I'm a Microsoft MVP for XNA/DirectX.

Visit my blog at AndrewRussell.net or follow me on Twitter @_AndrewRussell.


I am currently lead engine developer for River City Ransom: Underground.

My other game dev project - currently on hold - is Stick Ninjas, a 2D multiplayer platformer-shooter. There is a weekly DevLog video series about it, which you can watch on YouTube.

My previous projects include:

  • ExEn, a cross-platform port of XNA that runs on iOS, Android and Silverlight
  • Light Blocks: cross-platform falling-block game to demonstrate ExEn
  • Dark: A 2D physics-platformer with fancy lighting effects (PC and Xbox 360)
18h
awarded Popular Question
Aug
21
revised Why is the standard C# event invocation pattern thread-safe without a memory barrier or cache invalidation? What about similar code?
added 107 characters in body
Aug
21
answered Why is the standard C# event invocation pattern thread-safe without a memory barrier or cache invalidation? What about similar code?
Aug
21
comment Why is the standard C# event invocation pattern thread-safe without a memory barrier or cache invalidation? What about similar code?
I am not sure your re-ordering example is correct. According to this, the .NET 2.0 memory model guarantees that "Writes cannot move past other writes from the same thread."
Aug
21
revised Why is the standard C# event invocation pattern thread-safe without a memory barrier or cache invalidation? What about similar code?
added 46 characters in body
Aug
13
awarded Popular Question
Aug
5
awarded Notable Question
Jul
31
awarded Enlightened
Jul
31
awarded Nice Answer
Jul
22
comment Why is the standard C# event invocation pattern thread-safe without a memory barrier or cache invalidation? What about similar code?
volatile also inserts memory barriers (to ensure changes are visible between threads). But my question is why the given code is safe without a memory barrier. // The lock-free synchronization used by events that you refer to is only on the += and -= operators (not on access, which is what my question is about). It uses Interlocked.CompareExchange.
Jul
15
awarded Yearling
Jul
15
awarded Yearling
Jul
14
awarded Announcer
Jun
24
awarded Enlightened
Jun
24
awarded Nice Answer
Jun
12
awarded hlsl
Jun
10
comment Why is the standard C# event invocation pattern thread-safe without a memory barrier or cache invalidation? What about similar code?
So, start with P and Q being filled with garbage. CPU B sees this: "R is initialized, Q is initialized". We hope that CPU A sees "R is initialized, Q is initialized". But maybe it could see "Q is initialized... R is initialized". We don't want the latter ordering to happen -- but what prevents it from happening? It's clearly not magic - the compiler, JIT, and especially the CPU have to do something to enforce that, right?
Jun
10
comment Why is the standard C# event invocation pattern thread-safe without a memory barrier or cache invalidation? What about similar code?
@ChrisO Exactly. The read of memberFoo (or Q) is atomic. But the read of localFoo.baz (or R) is a separate step (as is the write, in the initialization). So what guarantees the ordering of those two things as visible between different CPUs?
Jun
10
comment Why is the standard C# event invocation pattern thread-safe without a memory barrier or cache invalidation? What about similar code?
Regarding your edit that links to the operator precedence table -- that is only relevant to code within a single thread of execution. Another thread observing that code executing can see things happening in a significantly different order.
Jun
10
revised Why is the standard C# event invocation pattern thread-safe without a memory barrier or cache invalidation? What about similar code?
added 151 characters in body
1 2 3 4 5