On 1/28/2010 3:57 PM, Richard Quadling wrote:
On 28 January 2010 21:38, Daevid Vincent<daevid@xxxxxxxxxx> wrote:
An intersting synopsis of "Semaphores". I've done similar things in the
past, but never knew this is what I was doing. LOL. Just like I've built an
uber XML parser/editor and didn't know that I actually built a "Factory".
Ahhh... good old data structures -- they didn't teach these things when
I was in college (20+ years ago).
I particularly found this part interesting as I hadn't considered this,
"What you _DON'T_ do, is see if the lock is already there before trying to
write one. No need and provides the possibility for another user,
using the same code, to be interleaved." I am assuming (and correct me if
I'm wrong) as you will get a race condition (on a sufficiently large
system) wherein, two users check "is there a directory lock", and the
system responds "No" to each, and then the code attempts to create a
directory. Then one of them gets a lock granted (i.e a directory) and since
'there can be only one' [highlander reference] the other one THINKS they
got the lock (too). Doh!
What happens in code depends upon the code.
If the code doesn't test the result of assigning the lock, then there
is no lock.
Every write will overwrite whatever was previously written if all
users use the same code.
And there is the major flaw of distributed or client initiated semaphoring.
It is entirely possible for you to open up your DB gui tool and amend
the data. Completely bypassing the semaphoring.
>>>
Would this support the idea of putting a lock column in the table to be
locked? If an admin had cause to go into a table with a DB gui tool,
at least he would see the semaphore as a "warning".
The same table would also simplify code and make the sb more portable.
As for speed, you have to query that (those) records to be updated
anyway at some point - a special lock table would require another query
and if it that lock table was for ALL the other tables in the system, it
would be getting more hits than any one table.
This has been very educational for me - thanks for the discussion.
- Ron
>>>
So, whilst semaphoring is really useful for long edits, it isn't perfect.
But as long as all code use the same semaphoring logic, then it is fine.
The wiki page is also interesting and I'd always heard these terms, but
never really knew what they were in a practical sense: "A mutex is a binary
semaphore that usually incorporates extra features, such as ownership,
priority inversion protection or recursivity. The differences between
mutexes and semaphores are operating system dependent, though mutexes are
implemented by specialized and faster routines. Mutexes are meant to be
used for mutual exclusion (post/release operation is restricted to thread
which called pend/acquire) only and binary semaphores are meant to be used
for event notification (post-ability from any thread) and mutual exclusion.
Events are also sometimes called event semaphores and are used for event
notification."
And this also helped to clarify:
http://stackoverflow.com/questions/62814/difference-between-binary-semaphor
e-and-mutex
Ha! Toilets.
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
