I know it is commonly used as a lock object, but is that really sufficient reason? What is the meaning of
object o = new object();
An non-abstract class is something that represents actual objects. "asdasdf" is a string. What actual instance can there be of "object" class? It doesn't make sense, OOP-wise. My question is if there is some practical reason for its existence (besides being used as a lock object).
Perhaps you can explain why it should be abstract / MustInherit ?
The easiest way to answer that question is to ask another one: is there any reason for the Object class to be abstract? Since there is no reason for it to be abstract, it's not.
Sometimes you just need an Object, and nothing else, such as when using a random reference type for things like implementing multithreading locks. Not making object abstract allows use in those situations. The Monitor.Enter and Monitor.Exit classes (which is the basis behind the "lock" keyword in C#) can acquire a lock on any given object, regardless of implementation.
Yes, that is sufficient. Either you allow object to be created or you have to create classes for each structure that's just looking for a static pointer that can be referenced. My guess is that there are other places this is used.
This is actually used quite a bit in System.Windows.Forms where plain old System.Object instances are created to act as keys into per Control instance dictionaries for things like event handlers and property values. Think of it as a poor man's DependencyProperty but without all the machinery built up around it (and thus no need to define an abstraction like the DependencyProperty class).
The CLR might even have some kind of support for optimizing memory usage of plain old System.Object instances since there are only a couple scenarios where they can be used beneficially.
Surely for a class to be abstract means that it has some functionality which requires implementation...
System.Object does everything it needs to thus it is not Abstract.
I think you misunderstand why things are made abstract, it's becuase they contain some useful functionality and don't dictate how you implement some parts of thier functionality.
Essentially they are half made classes, like a model kit, which you get to customise to work the way you want to, but you don't have to roll the whole thing from scratch.
They do not exist to stop you from creating instances of them.
it shouldn't have a public constructor and, I think, it should be abstract. The object class is the base of all .net objects and have no purpose by itself (ok, locking... but I prefer to have a class Lock : object and the problem is solved). The excuse "because it doesn't need to be abstract" is poor. We should have reasons to make classes concrete instead of abstract. We don't have any reason to make it concrete, so... it shouldn't, because the main purpose of this class is "to be inherited by all the other classes".