Subj : Re: recursive mutexes
To   : comp.programming.threads
From : Uenal Mutlu
Date : Wed May 18 2005 10:38 pm

"doug" wrote
>
> "Uenal Mutlu" wrote in message
> > "doug" wrote
> >>
> >> For the current code I'm working on, it would take me several hours,
> >> perhaps
> >> days, to type in the lock information his tool requires.
> >
> > If you strictly follow the deadlock theorem I posted here, then you can
> > be assured that no deadlock will happen.
> >
> >> That's not to mention the fact that threads are created dynamically, and
> >> their behaviour
> >> is unpredictable (I see nothing in his tool that allows you to grab this
> >> lock OR that lock, depending on some state.).
> >
> > It is intended for locks put on individual shared objects. Ie. it is not
> > for "locking threads" or something that.
> > It is irrelevant when the threads are created. It is important what the
> > threadproc does: ie. in which order it locks the objects.
> > The requirement is: you must create a list of all your shared objects (the
> > order
> > is irrelevant), then in each threadproc pick the objects you want to use
> > just in the same order as they are on the list.
> >
> >> All he's done is specialise hierarchical locking for simplified
> >> scenarios.
> >
> > Not true. The deadlock theorem I formulated is an important
> > generalization.
> >
>
> Again, not answering the points.  They are:
> - I cannot enumerate the list of locks.  Many are dynamically created on the
> fly (to protect a dynamically created piece of data).   There are hundreds
> of threads, and thousands of semaphores.  I cannot actually generate the
> input your program requires.  I see how it would be useful for small stuff,
> e.g. for a Uni project, though.

Actually, for nothing else it was intended.

> - Your theory provides no allowance for dynamic flow-of-control - i.e. the
> behaviour of the program must be completely predicatable a priori (or do you
> expect the user to sit and type is every possible combination of acquires
> for each thread??).

I must say that people sometimes unnecessarily complicate things.
Just make a lists of the shared objects and apply the deadlock theorem.
Just see how I did it in the other posting of today where a class with
3 independent data members had to be shared by an arbitrary number
of threads (even more than 1000).

> Therefore, it's a specialisation, not a generalisation.
> You have tightened the general rules of hierarchical locking to suit your
> restricted problem space.

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.

.