[Info-vax] counting-lock ?

[Richard Maher]

Hi Jeremy,

"Jeremy Begg" <jeremy.removethis at vsm.com.au> wrote in message
news:4AE666CD.7060108 at vsm.com.au...
> Hi Pierre,
>
> A lot of discussion about how to implement a queuing mechanism using
> distributed locks ... but perhaps you don't need to do it that way at all.
>
> It sounds like your DECnet objects use transparent task-to-task
> communication: DECnet creates a NET$SERVER process for each incoming
> connection, and the process runs your database query.  This is simple to
set
> up and simple to program, but gives you very little control.
>
> You might be better off by restructuring your application so that the
server
> uses "non-transparent" communication.  In this mode, the server process
> starts up before any client requests have begun.  The server declares
itself
> to DECnet as a network object, and then waits for incoming connections.
> Under this model your server can queue the work to be done and assign it
to
> any number of worker processes, all under the control of the central
server.
>
> Have a look at the "DECnet for OpenVMS Networking Manual" which you can
> download from the HP OpenVMS web site
>
http://h71000.www7.hp.com/doc/73final/documentation/pdf/DECNET_OVMS_NET_MAN.PDF
>

What a great Idea!

> Regards,
>
> Jeremy Begg
>
> Pierre wrote:
> > hi,
> >
> > I have a DECnet object which can serve various known queries on a
> > database. these queries are resource consuming and I don't want more
> > than (say) n=5 of them of the same type to run at the same time. I
> > want the other one to be queued up for further processing.
> >
> > I first thought of using the lock manager. this would have work with
> > an exclusive lock for n=1 but n>1...
> >
> > I then thought of using counting-semaphores but the problem with
> > semaphores is that if the server process unexpectedly die before
> > signaling the its done with the resource, the slot it was using is
> > never freed.
> >
> > as unfortunately the DLM does not have "counting-locks" I had the idea
> > of creating a null lock for every possible query type and as many
> > exclusive sub-lock as needed, one for every possible instance of that
> > particular query. for each new request of that type, the newly created
> > object instance enqueue one exclusive lock on every sub-lock. as soon
> > as one is granted, it first dequeue the unneeded ones and starts its
> > job.
> >
> > do you see any flow in this algorithm ? do you see any other way of
> > doing it ?
> >
> > TIA,
> > Pierre.
>