text: ?
  The shared constructor? It's guaranteed to run first, and to tun once, so it MUST be threadsafe, right? :)
  According to the specification the static constructor will only run once, and all concurrent acces to the type (static or instance) is hold up until the static constructor has finished.
  Cheers
  "the Common Language Infrastructure (CLI) spec that guarantees a type constructor will execute only once, unless explicitly invoked by user code. To enforce this guarantee in a multithreaded environment requires a lock to synchronize threads"
  Do you think the following class should use locks to be thread safe?
  public class Class1
  {
  private static IPEndPoint endPoint;
  private static UdpClient listener;
  private static int listenPort;
  static Class1()
  {
  }
  public static void ReceiveCallback(IAsyncResult ar)
  {
  listener.BeginReceive(new AsyncCallback(ReceiveCallback), s););
  //Process string here
  }
  public static void Start(int port)
  {
  if (listener == null)
  {
  listenPort = port;
  endPoint = new IPEndPoint(IPAddress.Loopback, listenPort);
  listener = new UdpClient(endPoint);
  UdpState s = new UdpState(endPoint, listener);
  listener.BeginReceive(new AsyncCallback(ReceiveCallback), s);
  }
  }
  public static void End()
  {
  if (listener != null)
  listener.Close();
  }
  }
  A few (one or two) times I got in trouble with that description which was in my mind and finally changed my logic to solve it.
  I had this exact question during a recent interview.
  JP - If Thread A calls Class1.Start it will create a new UdpClient. If Thread B calls Class1.Start it will overwrite that client. When ThreadA calls End, it can close the listener opened by ThreadB, so I'd sat this class would have issues in a multi-threaded program.
  Since the operations span methods you couldn't use a lock inside the class to manage this problem. Threads would need to take locks from Start() to End()
  The Start method should not overwrite the listener because it checks that listener is null before doing anything.
  Question about static events:
  If that class has a static event and ASP.NET Page instances suscribe to it, it seems that the pages will not be garbage collected as the hold a reference to the event. Also suscriptions will keep adding up.
  What is the best way to solve this? Unsuscribe the event in the Page unload, use Week References?
  - Think about two threads racing to get into Start at the same time. Thread A will check and see listener is null, then start creating a new endpoint. Thread B is there at the same time and also sees a null listener, and starts creating a new endpoint, too. There is nothing that prevents two threads from seeing a null listener.
  - Subscribing to static events from a page is a real pain. You would have to unsubscribe at some point. A weak reference might work, too, but this is a bit tricky. See:.
  I'd try to avoid the static event if at all possible.
  Once I discovered this myself, that's when I figured out how to use the SyncLock command, which gets around thread safety.
  You just have to be careful to keep the shared data locked for the shortest possible time, and be sure to include a Try/Catch for safety.