interview

• IDisposable

  • SupressFinalize in IDisposable

• Asynchronous programming in .NET

  • async/await
  • Avoid deadlock with async/await
  • Does async/await creates new thread?
  • CPU bound vs I/O bound tasks
  • SynchronizationContext
  • Threads/tasks
  • locking in .NET
    • locking with integer
  • TPL
  • ThreadPool

• Type system

  • Reference types vs value types
    • value types as fields in objects
  • What kind of types cannot be object field?
  • ref struct types
  • Strings in .NET
  • Data Structures
  • Generics
  • Covariance and Contravariance
  • Equals and GetHashCode

• Garbage Collector

There are 2 ways of writing OWIN middleware in ASP.NET Core.

• Pure OWIN - usefull if you want to integrate with OWIN compatible module but not written in C#
• ASP.NET Core OWIN middleware

ASP.NET Core Middleware:

This type of middleware can be:

• delegate of Func<HttpContext, Func<Task>, Task>
• class with IMiddleware imlementation

app.Use(async (context, next) =>
{
    // Do work that can write to the Response.
    await next.Invoke();
    // Do logging or other work that doesn't write to the Response.
});

Pure OWIN Middleware:

This rather would be used to integrate with OWIN middlewares written in different language, so that ASP.NET Core implementation directly is not possible.

• OWIN - Open Web Interface for .NET
• allows web apps to be decoupled from web servers
• defines standard way for middleware to be used in a pipeline to handle requests and provide responses
• ASP.NET Core applications can interoperate with OWIN-based applications, servers and middleware

Microsoft.AspNetCore.Owin package provides two adapter implementations:

• ASP.NET Core to OWIN
• OWIN to ASP.NET Core

This allows ASP.NET Core to be hosted on top of an OWIN compatible server/host or for other OWIN compatible components to be run on top of ASP.NET Core.

• ’tree like’ data structure
• each node is expression (method call, equality comparison, binary operation etc.) representing a piece of code
• you can compile expression tree and run code it represent
• enables dynamic code generation at runtime
• LINQ queries on DBs are implemented with Expression Trees
• used in the dynamic language runtime (DLR)
• anonymous lambda expression can be converted to ExpressionTree via compiler (i.e. x => x*2 can be represented as tree instead of delegate or anonymous lambda function)

Further read:

• lazy loading:

  • delaying load of data until we specifically request for it
  • i.e. accessing customer.Address loads Address of a customer in the background via separate SQL query
  • property needs to be public, virtual
  • context.Configuration.ProxyCreationEnabled should be true
  • context.Configuration.LazyLoadingEnabled should be true
  • to disable lazy loading completely Context.Configuration.LazyLoadingEnabled = false;

• eager loading

  • opposite of lazy loading
  • loads related entities as part of the query
  • done via .Include() query

Further read:

• enables implicit reference conversions for
  • arrays
  • delegates
  • generic type arguments
• Covariance preserves assignment compatibility
• Contravariance reverses assignment compatibility
• allows for matching signatures of delegates and method groups
  • to assign to delegates from method that returns more derived types - covariance
  • to assign to delegates from method that returns less derived types - contravariance
• Covariance and Contravariance are supported in Generics for implicit conversions for type parameters
  • allows method to have more derived return type than defined by generic type parameter of the interface
  • this allows implicit conversions from one generic interface to another (from IEnumerable<string> to IEnumerable<object> even if first does not inherits from second)
  • allows generic types to have less derived argument types than specified by the generic parameter of the interface (implementation of IEqualityComparer<BaseClass> can be implicitly converted to IEqualityComparer<DerivedClass> because IEqualityComparer.Equals is contravariant)
  • implicit conversions works for interfaces but not classes that implement from those interfaces (i.e. this won’t work List<Object> list = new List<String>())

Assignment compatibility is when object of a more derived type is assigned to an object of a less derived type.

Allow for:

• generalization of logic based on available types
• specify possible supported types
• re-usability of code
• type safety
• defers the exact specification of logic until the class or method is declared and instantiated by user code with all type parameters specified
• mostly used for collections (some non-generic versions of collection are not recommended like ArrayList i.e.)
• information of exact type parameters used in a generic can be obtained at runtime by reflection

Further read:

In table below official recommendations for choosing data structure for your needs:

Further read:

• lock statement blocks execution of a code block for single thread that hold lock
• the same thread can acquire and release lock again
• any other thread is blocked from the statement
• lock on dedicated instance only
• using the same instance on multiple lock statements may lead to deadlock
• avoid using as lock
  • this, as it might be used by the callers as a lock
  • Type instances, as those might be obtained by the typeof operator or reflection
  • string instances, including string literals, as those might be interned
• Hold a lock for as short time as possible to reduce lock contention.

Below code block is translated by compiler

• multi threaded programs usually uses one of the threads as means of synchronization
• there are message loops to pass unit of works (like Windows message queue)
• message queues require messages formats and convention for handling it
• single thread to handle ASP.NET request is waste of the resources (before .NET 2)
• thread pool was better but inconvenient to work with
• instead SynchronizationContext queues work for given context not thread
• thread have current context
• context does not have to be unique but can be shared between multiple threads
• thread can change context but this is rare
• SynchronizationContext keeps count of all asynchronous operations
• Windows Forms uses WindowsFormsSynchronizationContext
• WPF and Silverlight uses DispatcherSynchronizationContext
• Console app and WindowsServices and ThreadPool threads uses default SynchronizationContext
• ASP.NET uses AspNetSynchronizationContext

Further read:

In short: no.

Longer explanation:

• task that want to do I/O write call to driver write
• driver operations are performed asynchronously
• write operations on devices is done without CPU involved
• finish of writing is done via interrupt
• interrupt, schedules Deferred Procedure Call
• DPC schedules Asynchronous Procedure Call
• APC notifies thread that I/O write is done
• task that was doing I/O is scheduled with continuation of its method after I/O is done.
• some threads might need to be borrowed for handling APC and such but no thread is spawn to handle I/O

I recommend reading this post: https://blog.stephencleary.com/2013/11/there-is-no-thread.html . This will explain the topic much better than I can.

async/await syntax should be used for I/O bound asynchronous operations only.

public async Task<int> GetUrlContentLengthAsync()
{
    var client = new HttpClient();

    Task<string> getStringTask =
        client.GetStringAsync("https://docs.microsoft.com/dotnet");

    DoIndependentWork();

    string contents = await getStringTask;

    return contents.Length;
}

Compiler transforms code into a state machine that to track yielding execution for await and resuming execution when a background job is finished.

Things to keep in mind:

• async method needs await
• add Async suffix to asynchronous methods
• async void for ‘Fire and Forget’ work i.e. event Handlers
• be aware of mixing LINQ with async lambdas
• wait for tasks in a non-blocking manner (do not use Task.Result i.e.)
• for tight loops use ValueTasks
• Consider using ConfigureAwait(false) for performance and for avoiding deadlocks

Further read:

There are two types of asynchronous operations in .NET.

• I/O bound
• CPU bound

For I/O bound async/await syntax should be used. TPL should not be used for this. async methods does not spawns new thread to hand le I/O work asynchronously.

For CPU bound operations TPL should be used (Task.Run). This spawns new thread. Performance testing should be done to check if overhead of new thread and context switching is not greater than actual work to be done.

• informs GC that object does not need to be added to finalizer queue
• finalizer execution is not deterministic and objects can live for long time in queue - this is optimization technique
• to make sure that object disposes of any unamanaged resources even if Dispose will be not called we need to implement finalizer

Basically finalizer execution time is not deterministic. We cannot predict when this will be called and till that time - object is existing and still taking memory space. Since we are controlling creation and disposal of those resources we can say to GC: ‘Do not worry about that! It already had been taken care of!’. So this way object will be destroyed sooner, leaving this space to be used by something else possibly.

Example implementation of IDisposable

public class MyResource : IDisposable
{
    public MyResource(IntPtr handle)
    {
        this.handle = handle;
    }

    public void Dispose()
    {
        Dispose(disposing: true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if(!this.disposed)
        {
            if(disposing)
            {
                component.Dispose();
            }

            CloseHandle(handle);
            handle = IntPtr.Zero;
            disposed = true;
        }
    }

    ~MyResource()
    {
        Dispose(disposing: false);
    }
}

MyResource object have pointer which is unmanaged. This is why this class should implement IDisposable interface. Implementation should be correct according to recommended pattern (see below for documentation).

There a re few points to highlight here:

• software often waits for some I/O operation to complete (file operation, network call, database query etc.)
• we can use this time for something productive instead to wait for data to be available or I/O operation to be completed
• with asynchronous programming user can work in the meantime
• not waiting for I/O operations synchronously enhances user experience

Of course this problem is much more complex. Modern software operates on much more different PC architecture than 20 years ago. Nowadays software must be asynchronous to appear more user friendly and to made better use of modern multi CPU architecture. Right now complex, professional software uses multiple processes, threads on multiple CPUs (CPU you buy is not really *single* CPU) or even utilize GPU for more complex computations (like i.e. video editing software). Before that we mostly had single threaded desktop applications that had ‘please wait’ or ’loading’ pop ups. Right now this is song of the past really and to achieve better User Interfaces that allow to edit tag of your post without changing whole post. With mobile devices on the rise and sometimes lousy cellular network those kind of designs would not be sensible or sometimes impossible to implement. Did you ever happened to reenter some chunk of data into some software because you lost it? Maybe network was down? Or you hit back button by mistake? Right now it belongs to past mostly. All of those would be hard to do with synchronous operations. Right now people are bit spoiled and they tend to leave the page/application if it appears to be slow and not every company can sell ‘one-in-the-market-necessary-for-your-work-software’ that you will be forced to use. And this is why we have asynchronous operations and this is why we have asynchronous programming model that allows us to program such operations.