Comments (6)

  1. Joku says:

    Quote from the first link:

    "When you are programming with threads, you usually drive slow devices through synchronous library calls that suspend the calling thread until the device action compltes, but allow other threads in your program to continue. You will find no need to use older schemes for asynchronous operation (such as i/o completion routines)."

    Wha ha? I always thought using the Begin… End… asynchronous methods to take advantage of IO completion ports in network programming on .NET was the preferred method when scalability/performance was necessary. This quote seems to suggest that it is "older scheme". What should I make of this, write my future programs using other than Begin… End… when using socket and stream classes?

  2. Judah says:

    I predict that multithreading will remain an inexact and difficult science until we get language abstractions and compilers that force developers to write safe multi-threaded applications.

    Even as a .NET ‘veteran’, I still find it difficult — extremely difficult! — to write good, mulithreaded code that has zero problems with it.

  3. Joku says:

    This is a nice article about sockets in .NET:

    The conclusion seems to be that you pick either more performance or better scalability. I guess you can get both but that probably comes at the cost of going lower level and subtle problems that come with more complexity.

    Well choice is good 🙂

  4. Birrell seems to use the "lock" statement exclusively and does not offer a correct way to obtain mutual exclusion without deadlock avoidance. The "lock" statement has no timeout options. The best practice seems to be to use Monitor.TryEnter() instead:

    if (Monitor.TryEnter(this, 300))




    // Place code protected by the Monitor here.









    // Code to execute if the attempt times out.