Locking Schema on BlogEngine.NET

Topics: Business Logic Layer
May 27, 2008 at 4:42 AM

I looked into the source code of BlogEngine.NET. There are a lot of singleton pattern usages used for caching purpose. For example the Post class has Posts static variable implemented as singleton that caches all posts available in a blog.


I believe the static variable is a shared resource. When accessed via web application, there could be many threads that access this shared resource from many web requests. Then it makes sense when writing to the static variable, the Post class acquires lock on the _SyncRoot static variable. But I don’t see a lock attempt when modifying this shared resource, for example:


Post newPost = new Post();

newPost.Property1 = …;



Based on my understanding, altering shared resource is a non-thread-safe action. When we alter this shared resource, there could be other threads reading on the same resource. But, I also understand that trying to acquire the same lock for reading operation is not the right solution since it will affect the performance of the application dramatically.


So, my question is why not using the reader-writer locking schema? Reader-writer schema is suitable here since the shared resource will often be read than written.



Agus Suhanto

Jun 1, 2008 at 1:34 PM
Visual Studio load test answered my question above. I set up the load test simulating 50 users that access my website simultaneously. And indeed shared resources must be really carefully accessed/altered in multi threading environment. (Web application is naturally a multi-threaded application).

Locking (the critical section) in get accessor of singleton' property is absolutely required. This is to ensure that a singleton is really single object. However, reading and writing to the singleton must also be guarded by locking mechanism. When a thread is reading the shared resource, in the middle of process no other thread should be allowed to write on it. On the other hand, when the shared resource is written, other threads must wait until writing process is done. Furthermore, we should allow many threads to read on the shared resource at the same time, and only allow one thread to write on the shared resource at any given time.

The shared resource is read often then written. This is typical in a web log application like BlogEngine.NET. Someone may only write 1 or 2 posts in a week, but his or her blog can be read by many people in a day.

According to MSDN documentation, the locking schema that is suitable for this purpose is reader writer lock. So suggest the BlogEngine.NET team, if they still continue to use singleton as caching mechanism, I think they should implement reader writer lock schema to guard shared resources.

Any comment?

Agus Suhanto
Jun 5, 2008 at 9:20 PM
The singleton mechanism in BlogEngine.NET is not only used in the domain model, but also in writing controls like CategoryList and TagClouds. There you can see that the "html" to render the control is generated once and cached to a singleton. When there's a new post or category this singleton is then renewed by assigning the singleton with null values.

In load testing simulation I found that some request fail generating the content of these controls because when trying to initialize the content other request nullifies it (a race condition). So I guest, it should be mandatory to guard the code that nullify the singletons with critical section.

Agus Suhanto