Subj : Re: recursive mutexes
To   : comp.programming.threads
From : Giancarlo Niccolai
Date : Sat May 21 2005 01:07 pm

Uenal Mutlu wrote:

 
> It is not hierarhical locking. My method sees all objects as being
> independent of each other. If you must build hierarchies then you
> can do this by simply locking each object in order of its hierarchy.
> For example: oDatabase, oTable, oField    would be locked as follows:
>   oDatabase.lock();
>   o.Table.lock();
>   oField.lock();
> now all 3 are locked hierarchically (in the same thread of course).
> As such, my method is flexible to create even such hierarchies on the fly.
> This technique was also used in the above mentioned solution.

Interesting (Ironically).
If the whole database is locked, that means that no other thread should
access it; so, locking the table and the field is pointless.
If another thread tries to access the locked field without locking the
database first, there something wrong in the other thread logic, because it
does not respects the locking scheme of the first thread.
If a thread would be able to act on the database by just locking the field,
then there would be no need to lock the database.
Take it from the point you like, an application designed this way is doing
something dumb. I don't say it won't work (even if like someone other
pointed here, you are loading a gun this way), yet it's *at least* dumb and
the application would run smoother by locking exactly what you need when
you need it.

You are not the first person in the history that is committing this kind of
mistakes. 

Syllogism: I.e. Java designers did it long before you did. Java is a big
project and works. Hence big project can have thread design flaws and still
work.

Yet it doesn't work WELL. Butenhof, Swartz and other ppl much more expert
than me have already explained why, so I won't descend into details.

Bests,
Giancarlo Niccolai.

.