I've been doing quite a bit these past few days with Thread Local Storage -
specifically using the ThreadStatic attribute.

... but last night, I got to thinking. When .Net code is running, it's
running on a Managed Thread, not (directly) an O/S thread. There's no
guarantee made that, from timeslice to timeslice, code will actually be
running on the same O/S thread. I don't think any CLR versions swap out the
O/S thread today, but depending on the hosting model it's a possability.

To comabt this, the CLR team has added two atrributes to the Thread
namespace:
BeginThreadAffinity
EndThreadAffinity

Now, by using Thread Local Storage (either a Named or Unnamed data slot, or
simply via the ThreadStatic attribute) I absolutly have Thread Affinity. I'm
trying now to figure out if I need to use the Begin/End ThreadAffinity
methods on my processing. If so, it's.. going to be ugly. I can't really
tell, from the documentation, if this is the case. Logically, it seems like
they should be required, but given the ensuing complexity, I can't really
see it.

My Thread Local stuff is all encapsulated in a class, that looks like:

public class Context
   {
       [ThreadStatic()]
       private static Context _current;
       private string _value;

       public Context(){ _current = this; }
       public static Context Current
       {
           get { return _current; }
       }

       public string Value
       {
           get { return _value; }
           set { _value = value; }
       }
   }

Is there a better way to accomplish this same task? I see (via Reflector)
that ASP.Net actually uses Remoting Contexts to have Context.Current work
properly. Would I be better off using a context bound object (the same way
System.Transaction works)?