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)
Jul
2
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
Jun
10
awarded Nice Question
Jun
10
comment Why is the standard C# event invocation pattern thread-safe without a memory barrier or cache invalidation? What about similar code?
Ok, so "B will never get the reference to R before R's constructor has run" --- but what exactly is it that ensures that the result of "R's constructor has run" is visible to CPU B, before or at the point where the modification of Q is visible to CPU B? There's no explicit memory barrier to ensure that ordering. So it must be something else.
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 some notes to clarify that the question is not a typical thread-safety question.
Jun
10
comment Why is the standard C# event invocation pattern thread-safe without a memory barrier or cache invalidation? What about similar code?
The immutability thing isn't really relevant (I've amended the question to clarify that). I'm not sure the thing about CPU cache answers the question. I understand how GC compaction works. I'll make another edit that might hopefully make things more clear.
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 some notes to clarify that the question is not a typical thread-safety question.
Jun
10
asked Why is the standard C# event invocation pattern thread-safe without a memory barrier or cache invalidation? What about similar code?
Jun
8
comment how to show lots of sprites from one texture and have them move at intervals XNA 4.0
@Kokodoko Game1.LoadContent gets called once at startup (pedantic: it can get called again in rare device-lost situations). So the call to Asteroid.LoadContent also only happens once. But, even if it were called multiple times, XNA's ContentManager.Load keeps a lookup of all loaded content (until you call Unload) - so even if you wrote code that called Load repeatedly, you'd keep getting the same object back.
May
1
awarded Populist
Apr
8
awarded Popular Question
Apr
8
comment Handle a canvas in a windows form application
@Riptide This answer is for a "Windows Forms Application".
Apr
7
awarded Caucus
Apr
6
answered Handle a canvas in a windows form application
1 2 3 4 5