Hi,
----- Original Message -----
From: "Timothy Smith" <tim@stripped>
To: "Paul Cadach" <paul@stripped>
Cc: <monty@stripped>; <internals@stripped>
Sent: Friday, September 07, 2001 3:38 AM
Subject: Re: LOCK TABLES on compressed tables...
> On 2001 Sep 07, Paul Cadach <paul@stripped> wrote:
> >
> > For my situation I don't want to block reads, but make sure
> > other thread is waiting until lock will be released.
>
> Paul, I'm sorry but I don't understand. When we say "block
> reads", we mean exactly what you just requested: any threads
> which want to read from the table would wait (be blocked)
> until the lock is released.
LOCK can provide blocking of other threads on 3 stages:
1) when LOCK TABLE command issued;
2) when SELECT (i.e. read) from locked table executes;
3) when INSERT/UPDATE (i.e. write) to locked table executes.
For me, I want to have a lock which blocks other threads only at (1) stage,
not at (2) or (3).
For now, READ lock blocks threads at stage 3, and WRITE lock blocks threads
at stages 1, 2 and 3.
[skip]
> Why do you need this?
>
> I think you want this to happen:
[skip]
This is a scheme of my mind:
thread-1: LOCK TABLES a READ WAIT: <OK - not blocked>
thread-2: SELECT * FROM a: <OK - not blocked>
thread-1: SELECT * FROM a: <OK - not blocked>
thread-2: LOCK TABLES a READ WAIT: <Blocked>
thread-1: UNLOCK TABLES <OK - not blocked>
thread-2:
<Unblocked>
> What happens right now is:
>
> thread-1: LOCK TABLES a READ: <OK - not blocked>
> thread-2: SELECT * FROM a: <OK - not blocked>
thread-2: LOCK TABLES a READ: <OK - not blocked>
> thread-1: SELECT * FROM a: <OK - not blocked>
> thread-1: UNLOCK TABLES: <OK - not blocked>
>
> What I don't understand is why you need thread-2 to be blocked.
If thread-2 issues LOCK TABLES a READ when thread-1 holds the same lock,
thread-2 will not be blocked. :(
WBR,
Paul.
