MySQL Lists are EOL. Please join:

List:Internals« Previous MessageNext Message »
From:Timothy Smith Date:September 6 2001 8:38pm
Subject:Re: LOCK TABLES on compressed tables...
View as plain text  
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.

So I do not understand your sentence above.  It sounds like
you actually DO want to block reads.

> For this, I uses WRITE lock which blocks other threads until
> lock exists but also blocks reads from locked table(s) :(((

Is the frown because you can't use a WRITE lock, but would like
to?

Or is the frown because the WRITE lock blocks reads from the
locked tables?

> I.e. its looks like to have READ lock with WAIT option which
> blocks other threads when they tries to make READ WAIT lock
> until other READ WAIT lock exists. Threads which not uses locks
> must works transparently.

Why do you need this?

I think you want this to happen:

    thread-1:   LOCK TABLES a READ WAIT:   <OK - not blocked>
    thread-2:   SELECT * FROM a:           <Blocked>
    thread-1:   SELECT * FROM a:           <OK - not 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-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.

Imagine this scene:
    thread-2:   SELECT * FROM a:           <OK - not blocked>
    thread-1:   LOCK TABLES a READ WAIT:   <OK - not blocked>
    thread-1:   SELECT * FROM a:           <OK - not blocked>
    thread-1:   UNLOCK TABLES:             <OK - not blocked>

Even with the hypothetical READ WAIT lock type, thread-2 does not
block.  The only difference is that thread-2 happens to make the
request just before thread-1 acquires the READ WAIT lock, instead
of just after.  Since these are independent events, you can't
guarantee that thread-1 will hold the lock before thread-2 tries
to read.

That is why I do not understand the need you have.

Tim

P.S.  When I said earlier that it looked like a mis-feature
of MySQL that should be fixed, I wasn't thinking straight.  I
thought you could not ask for a READ lock and a WRITE lock at the
same time, but of course that is not true.

-- 
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /    Tim Smith <tim@stripped>
 / /|_/ / // /\ \/ /_/ / /__   MySQL AB, Full-time Developer
/_/  /_/\_, /___/\___\_\___/   Boone, NC  USA
       <___/   www.mysql.com
Thread
LOCK TABLES on compressed tables...Paul Cadach5 Sep
  • Re: LOCK TABLES on compressed tables...Sinisa Milivojevic6 Sep
  • Re: LOCK TABLES on compressed tables...Paul Cadach6 Sep
    • Re: LOCK TABLES on compressed tables...Michael Widenius6 Sep
  • Re: LOCK TABLES on compressed tables...Timothy Smith6 Sep
  • LOCK TABLES on compressed tables...Michael Widenius6 Sep
  • Re: LOCK TABLES on compressed tables...Paul Cadach6 Sep
    • Re: LOCK TABLES on compressed tables...Timothy Smith6 Sep
  • Re: LOCK TABLES on compressed tables - READ WAIT lock type...Paul Cadach7 Sep
  • Re: LOCK TABLES on compressed tables - READ WAIT lock type...Dana Powers7 Sep
  • Re: LOCK TABLES on compressed tables - READ WAIT lock type...Paul Cadach7 Sep
    • Re: LOCK TABLES on compressed tables - READ WAIT lock type...Timothy Smith7 Sep
  • Re: LOCK TABLES on compressed tables - READ WAIT lock type...Paul Cadach7 Sep
    • Re: LOCK TABLES on compressed tables - READ WAIT lock type...Benjamin Pflugmann7 Sep