Subj : Re: recursive mutexes
To   : comp.programming.threads
From : Uenal Mutlu
Date : Sat May 21 2005 02:50 pm

"Giancarlo Niccolai" wrote
> 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.

I would say that we are actually saying the same thing.
The maybe difficult to understand thing is that I have
_independent_ objects, so a field knows nothing about
the fact that it belongs to the table, and table knows nothing
about the fact that it belongs to database.
This might maybe seem not good for some people.
But as I demonstrated it is a flexible, general purpose method.
With my method, such dependencies (hierarchies) you have
to describe yourself, ie. "on the fly" (dynamically), there is no
need to have this link information be statically encoded, just
lock the individual items to form the group for operations on this
group (set) of objects.

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

I feel comfortable because it doesn't apply to me.

> 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.

.