Hi Ben,

Just addressing the locking things for now, not the
code review stuff. Although I'm interested to find
out if we really have a problem with sqlite3OsRead().
(wow)

> ... been reviewing the locking model for about
> four hours now to get to this point ...

Thanks for this. It is much appreciated by all
concerned I assure you. Everyone else who has been
helping too.

I put in some more comments about the implementation
of the locking model, and what it is supposed to do.
Some are reproduced below. You're right that the
current model would deadlock if blocking locks were
substituted in. It would be better if this were not
the case. 

The RESERVED/PENDING state mechanism reduces the 
requirement some though.

Another thing to keep in mind is that transactions
are atomic across multiple databases now. This means
that if you're in a transaction you can't drop
a read-lock on a database you have read from until
after the transaction is concluded.

Any more ideas/clarifications are welcome. It's a 
prety complicated topic, I'm still trying to get my
head around it all.

Dan.  

/*
** The following values may be passed as the second
** argument to sqlite3OsLock(). The various locks
** exhibit the following semantics:
**
** SHARED:    Any number of processes may hold a
**            SHARED lock simultaneously.  
** RESERVED:  A single process may hold a RESERVED
**            lock on a file at any time. Other
**            processes may hold and obtain new SHARED
**            locks.  
** PENDING:   A single process may hold a PENDING lock
**            on a file at any one time. Existing
**            SHARED locks may persist, but no new
**            SHARED locks may be obtained by other
**            processes.  
**
** EXCLUSIVE: An EXCLUSIVE lock precludes all other
** locks.
**
** PENDING_LOCK may not be passed directly to
** sqlite3OsLock(). Instead, a process that requests
** an EXCLUSIVE lock may actually obtain a PENDING
** lock. This can be upgraded to an EXCLUSIVE lock by
** a subsequent call to sqlite3OsLock().
*/

/* The following describes the implementation of the
** various locks and lock transitions in terms of the
** POSIX advisory shared and exclusive lock primitives
** (called read-locks and write-locks below, to avoid
** confusion with SQLite lock names). The algorithms
** are complicated slightly in order to be compatible
** with windows systems simultaneously accessing the
** same database file, in case that is ever required.
**
** Symbols defined in os.h indentify the 'pending
** byte' and the 'reserved byte', each single bytes at
** well known offsets, and the 'shared byte range', a
** range of 510 bytes at a well known offset.
**
** To obtain a SHARED lock, a read-lock is obtained on
** the 'pending byte'.  If this is successful, a
** random byte from the 'shared byte range' is
** read-locked and the lock on the 'pending byte'
** released.
**
** A process may only obtain a RESERVED lock after it
** has a SHARED lock.  A RESERVED lock is implemented
** by grabbing a write-lock on the 'reserved byte'. 
**
** A process may only obtain a PENDING lock after it
** has obtained a SHARED lock. A PENDING lock is
** implemented by obtaining a write-lock on the
** 'pending byte'. This ensures that no new SHARED
** locks can be obtained, but existing SHARED locks
** are allowed to persist. A process does not have to
** obtain a RESERVED lock on the way to a PENDING
** lock.  This property is used by the algorithm for
** rolling back a journal file after a crash.
**
** An EXCLUSIVE lock, obtained after a PENDING lock is
** held, is implemented by obtaining a write-lock on
** the entire 'shared byte range'. Since all other
** locks require a read-lock on one of the bytes
** within this range, this ensures that no other locks
** are held on the database. 
**
** The reason a single byte cannot be used instead of
** the 'shared byte range' is that some versions of
** windows do not support read-locks. By locking a
** random byte from a range, concurrent SHARED locks
** may exist even if the locking primitive used is
** always a write-lock.
*/






                
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to