The cool world of node.js

Hello! If you know me or if you have read my blog you know I like C#, a lot. However …
I cannot help to notice that C# has its shortcomings especially when it comes around web, webservices and usually it’s not particularly easy to do simple stuff and sometimes comes with a lot of code, code which you don’t really need. I have been experimenting with node.js in the past couple of weeks and I could already see some strengths which blow C# out of the water. I’ll go through some of those strengths, my experience with the language and maybe I’ll even start some tutorials on it as javascript has become my second favorite language of development. You may want to read this paragraph again, hah.

Things I really like about node.js:

  • great package manager(npm). Specify your dependencies in a json file(package.json) and run npm install and all your dependencies are there. That easy!
  • very fast. To understand this: I have this little thing in C# and while I use multiple threads in took more than 5 minutes to complete. Did the same thing in node.js and it was completed in less than one minute. What?!?! Development time was considerably shorter and I could even argue that number of lines of code was considerably shorter even though node.js is much newer to me compared to C#.
  • inherently asynchronous but single threaded. Goodbye thread synchronization issues but be careful to heavy cpu work as it can render your application unresponsive
  • it has some sort of LINQ called ArrowFunctions. We all love lambdas!
  • lightweight libraries for frontend, backend and everything else
  • very very very easy to use with json data format.
  • sure it’s cross-platform
  • very easy to build APIs

For development I used Webstorm because it gives the feeling of an IDE with debugging, watcher and everything nice. But feel free any text editor with some javascript plugin. You can get Webstorm for free if you are doing open source projects or use it for education purposes.

As a conclusion I’d say that the most impressive thing about node.js is the simplicity with which you can build stuff, not to mention speed. I am sure there are shortcomings to this technology as well but I am yet to discover.

See you soon on get started with node.js.

npm start


Threading in C#: Part IV

In the last couple of posts I talked about threading in C#, dangers and advantages. Now I am going to present collections that you can use in an environment where threads are heavy used. So what’s the issue that we’re trying to solve here? Assuming that you have a queue or a stack or whatever, two threads accessing it at the same time will result in an exceptio. Concurrent collections solve this problem but while they’re guaranteed to be thread safe, the code that is using them is not meaning that you can still have issues if you don’t design your code carefully. An example of such a poor design can be found below:

[code lang=”csharp”]
var _queue = new ConcurrentQueue<int>();
if (!_queue.Contains(5))

While the collection itself is thread safe, the entire code is not. Why? Assuming you have two threads one of them could be just after the if, and the other one testing the condition. Obviously they will both introduce a 5 in the queue and thus inducing an undesired behavior.

Now, all collections reside under System.Collections.Concurrent and they allow you to use concurrent stacks, queues, bags and dictionaries. Keep in mind that while they provide thread safety(assuming your code is clean) they have significant performance drawbacks, normal collections being faster, up to three times faster than the safe ones.
There is another danger that you may not realize immediately. Two different threads can action upon the same collection, while one is iterating through the other one can write. While in normal collection this would throw an exception, this doesn’t happen with concurrent collections and the result is nothing but gibberish.
They are designed to perform well under heavy threading usage and thus sacrificing some performance and memory efficiency. Their underlying implementation relies on linked lists which are much less likely to have problems due to the fact that inserting/deleting elements is a just a matter of updating a couple of references compared to traditional lists where hundreds of elements are to be moved around.

As opposed to traditional collections, these provide special methods TryAdd/TryTake exposed by IProducerConsumerCollection<T> interface which is implemented by all concurrent collections except for the dictionary. These methods are testing if the operation is possible and if so it’s performed but this process happens in an atomic way removing the need of locking this statement.

Collections provided by System.Collections.Concurrent:

  • ConcurrentStack<T>
  • ConcurrentQueue<T>
  • ConcurrentBag<T> (none)
  • BlockingCollection<T> (none)
  • ConcurrentDictionary<TKey,TValue>

Out of those, ConcurrentBag and BlockingCollection do not have non-concurrent equivalents, for the others I am sure you can guess them and because of this I will not dwell on them as their usage is rather rare. Below you’ll find brief usages of the others.


[code lang=”csharp”]
// All operations are atomically executed!
int value = 0;
var _stack = new ConcurrentStack<int>();
_stack.Push(value); //pushes 0
_stack.PushRange(new []{1,2,3,4}); // pushes an array of elements. stack: {0,1,2,3,4}
_stack.TryPeek(out value); // sees top of the stack: 4
_stack.TryPop(out value); // removes the last element. stack: {0,1,2,3}
_stack.TryPopRange(new[] {2, 3}); // removes an array of elements. stack: {0,1}
_stack.TryPop(out value); // removes al ement. stack: {0}
Console.WriteLine(value); // prints out 1


[code lang=”csharp”]
var _queue = new ConcurrentQueue<int>();
_queue.TryPeek(out value);
_queue.TryDequeue(out value);


[code lang=”csharp”]
int key = 0;
int value = 99;
int newValue = 100;
int comparisonValue = 99;
var _dict = new ConcurrentDictionary<int, int>();

_dict.TryAdd(key, value); // adds a new pair to the dictionary
_dict.ContainsKey(key); // returns true
_dict.TryGetValue(key, out value); // gets the value, without removing it
_dict.TryRemove(key, out value); // gets and removes the value
_dict.TryUpdate(key, newValue, comparisonValue); // replaces the value with a newValue based on the comparison with the comparisonValue

Another question that I’ve been asked a lot is around atomic operations in C# and I want to address it now with the following answer:
Reads and writes of the following data types are atomic: bool, char, byte, sbyte, short, ushort, uint, int, float, and reference types. In addition, reads and writes of enum types with an underlying type in the previous list are also atomic. Reads and writes of other types, including long, ulong, double, and decimal, as well as user-defined types, are not guaranteed to be atomic.

Threading in C#: Part III


Hello, as promised this is a continuation of Part II of the C# threading series. I hope you your time is well spent here.

Exclusive locking ensures that only one thread can access a particular section of the code at any given time. The main mechanisms used for exclusive locking are lock and mutex.
For non-exclusive locking semaphores are used. The difference between the two is that while locking is easier and faster, mutex allows to span locking across applications and different processes, for instance a common resource like a file.

[code lang=”csharp”]
class Test{
int x=5;

void Calc(){

This class is not thread-safe and the output is unpredictable. The thread safe code is to be found below and makes use of locks.

[code lang=”csharp”]
class Test{
int x=5;
object _lock = new object();

void Calc(){

Only one thread can lock the synchronizing object at a time, while any other threads are blocked until the lock is released.
If other threads are trying to lock the object they’re going to be served in a queue but with no guaranteed order. Threads that are waiting for accessing a locked area are in a WaitSleepJoin state.
There is a trick here: if an exception happens in the lock section then that part of the code won’t be released and other threads will be waiting for ever. Aside from that there are more subtle details here on Monitors but won’t get into that now.

Deadlocking is one of the hardest problems in multi-threading, especially when there are many objects that interact with each other. The main problem is that you can’t be sure what locks your caller has taken out.
So, you might lock a private field a within your class X, unaware that your caller (or caller’s caller) has already locked the field b within class Y. Meanwhile, another thread is doing exactly the reverse, creating a deadlock.
Another example of deadlocking arises when calling Dispatcher.Invoke (in WPF) or Control.Invoke (in Windows Forms) while in possession of a lock. If the UI happens to be running another method that’s waiting on the same lock, a deadlock will occur. This can often be fixed simply by calling BeginInvoke instead of Invoke. Alternatively, you can release your lock before calling Invoke, although this won’t work if your caller took out the lock.
So be careful, locking is great but dangerous and as far as performance goes, locking is fast, nanoseconds fast.

Mutex, yey!
They basically do the same thing as locks but across processes. One common use case is to ensure that an application runs on a machine as a single instance.
Performance-wise mutex is slower than lock and it’s done in order of microseconds.

[code lang=”csharp”]
class Test
void Main()
// Naming a mutex makes it available computer-wide.
// Ensure you have a uniqure name for it.
using (var mutex = new Mutex(false, "nameOfTheMutex"))
// Wait a few seconds in case there is another
// application in the process of shutting down.
if (!mutex.WaitOne(TimeSpan.FromSeconds(3), false))
Console.WriteLine("Another instance is running.");

void RunMyApp()
Console.WriteLine("Running. Press Enter to exit");

Semaphores or in other words traffic lights.
They have a limited capacity defined by user, once full everyone has to wait outside until someone leaves.
They’re particularly useful when one wants to limit the maximum number of threads that can execute a piece of code at the same time.
Like mutex, a semaphore can span across multiple processes by naming it and thus limiting the number of applications that can run in parallel.
Below you can find an example for semaphore usage:

[code lang=”csharp”]
class Test
// define a capacity of three
private static Semaphore _semaphore = new Semaphore(0, 3);

void Main()
for (int i = 1; i &lt;= 5; i++) new Thread(TestThread).Start(i);

void TestThread(object id)
Console.WriteLine(id + " tries to get in");
Console.WriteLine(id + " is in!");
Thread.Sleep(1000 * (int)id);
Console.WriteLine(id + " leaves");

That’s all, see you on the next posts on Thread Safety and Concurrent Collections!

Threading in C#: Part II

This is a continuation of threading in C# covered here. In this article I am going to cover more usages of threading, particularly timers and UI threading.

Multi-threaded Timers live in System.Threading.Timer and System.Timers and they represent one of the most common use case for repeatedly executing an action such as polling information and checking for a resource change. However the latter one is a wrapper around the first one and I’ll cover only the second one.

[code lang=”csharp”]
Timer timer = new Timer();

// define interval of execution
var interval = TimeSpan.FromSeconds(5);
timer.Interval = interval;

// assign a method to the elapsed event
timer.Elapsed += PerformAction;
timer.Start(); // Start the timer
timer.Stop(); // Stop the timer
timer.Dispose(); // Permanently stop the timer

// this is fired every 5 seconds
void PerformAction(object sender, System.Timers.ElapsedEventArgs e){
// example of updating WPF UI controls from another thread
Action action = () =&gt; txtMessage.Text = message;
Dispatcher.Invoke (action);

Such timers use the thread pool to allow for only a few threads to be used for many timers and thus avoiding wasting threads. That means that the event can be fired on a different thread every time and because of that they will fire regardless if the previous callback finished or not and that is dangerous. Why? Because dead locks can happen and then multiple event firings can and will ultimately crash your application by using all threads available. I’ve seen this happening therefore those event handlers must be thread safe.
Those timers are fairly precise within a 10-20ms range depending on OS, system load.

There is a catch with this one though: you can not update controls directly, whether they are Windows Forms control or WPF controls and you’ll have to use Control.Invoke and Dispatcher.Invoke respectively.

Single-threaded timers live in System.Windows.Forms.Timer  and System.Windows.Threading.DispatcherTimer namespaces and their main purpose is to get rid of the thread safe issue. They fire on the same thread as the one that created them which is basically your application. Beside that there are other advantages such as you don’t have to worry about using Control.Invoke or Dispatcher.Invoke in order to update your UI elements as those live on the same thread as you UI and they won’t fire until previous tick completed. That being said there is one huge downside, that is performing heavy work in the timer tick will render your application ultimately unresponsive. This makes them suitable only for small jobs such as counters or things like that.

Speaking of UIs you almost have no choice but using threading and the best practice there is to use one(or a few) UI threads and delegate any heavy lifting on background threads which at the end update the UI controls with the relevant data.


That’s all for now, see you on next article on dead locking, concurrency and concurrent collections. I have the feeling it’s going to be a lengthy one. Stay safe, stay thread safe!

Threading in C#: Part I

I’ve been asked so many times to address this topic but as you may already know it’s a bit complex to say the least and needs to be covered extensively since you can find use cases roughly everywhere. Threads are usually managed by a thread scheduler that ensures that all active threads are given CPU time and the threads that are waiting or blocked (for instance waiting for a resource to be freed or waiting for user input) do not consume any CPU time.

Typical use cases are those when you want to do multiple things at the same time, such as time expensive IO operations(download file, write in a file, read from database etc) or image processing etc and maintaining the rest of your application responsive. For example UI applications or servers are great examples for heavy thread usage. Now, as good as threads may be they can pose serious problems such as locking and memory leaks especially when used incorrectly. As I said earlier one of the most common issue is data sharing between threads or in other words how do the threads access a common resource without ending up in a deadlock. A deadlock is a situation where two(or more threads) are waiting for the other(s) to finish it’s job with the resource and as such it never does. So you have to be really careful when you’re sharing data between threads typically using a lock mechanism such as monitors, mutex or a semaphore to prevent that from happening. As for collections, C# provides you with thread safe collections: queues, stacks, dictionaries, you name it which all reside under
System.Collections.Concurrent namespace which it is a topic by itself that I’ll cover some other time.

Relevant namespaces for working with threads are System.Threading and System.Threading.Tasks. The first one is the old way of dealing with threading and it has been a while from .NET framework 2.0 while the latter one has been around only from .NET 4.0 and it somewhat simplifies threading. And then there is Task Parallel Library which is now the standard way.

Thread pool recycles threads and manages the number of threads that can be run in total such that once the maximum limit is reached, the jobs are queued and executed once a thread is freed. The Task Asynchronous Pattern(TAP) is an advanced and rather new mechanism that uses threads very efficiently and thus making applications much faster.

Using TPL(Task Parallel Library) starting new threads is extremely easy and resumes to a call like the one bellow:

[code lang=”csharp”]Task.Factory.StartNew(() => { Console.WriteLine("Hello"); });[/code]

Ofcourse I made use of lambdas there but basically you can use any delegate or method for that matter. Sure, you may ask yourself what if the method signature is not void, what if I want to get back some result. Sure you can do that:

[code lang=”csharp”]
// The <string> type argument for Task.Factory.StartNew
// is not necessary as it is inferred and you can remove it.
// Start the task executing:
Task<string> task = Task.Factory.StartNew<string>(() => GetMyCustomer());

// We can do other work here and it will execute in parallel:

// When we need the task’s return value, we query its Result property:
// If it’s still executing, the current thread will now block (wait)
// until the task finishes:
string customer = task.Result;

Any unhandled exceptions are automatically rethrown when you query the task’s Result property and are wrapped in an AggregateException. However, if you fail to query its Result property (and don’t call Wait on the task) any unhandled exception will take the process down. You can find an example on how to handle such situations bellow:

[code lang=”csharp”]
Task<string> task = Task.Factory.StartNew(() => GetMyCustomer());
catch (AggregateException aex)
foreach (Exception ex in aex.InnerExceptions)

Alright, so you’ve learned some basics about threading in C# will continue this series as following:
Part II – More usages of threading(Timers, Dispatchers)
Part III – Concurrency, Concurrent Collections
Part IV – Task Asynchronous Pattern(TAP)

Simple Share Buttons