Re: Avoid Locking Entire Hashes

Even some DB's such as SQLite don't do "row locking" (as opposed to full table locks). On MySQL myisam tables don't row-lock, whereas innodb tables will. If it's becoming an issue, you may need to look at performing all of your shared-hash writes grouped together, in as few places in the script as possible to minimize the possibility of other threads blocking during a lock. It would be a similar philosophy to the old adage, "Print seldom, print late." If that's not cutting it, you could migrate to a database with row-locking support.

Dave

Comment on Re: Avoid Locking Entire Hashes

Replies are listed 'Best First'.
Re^2: Avoid Locking Entire Hashes by jagan_1234 (Sexton) on Jun 13, 2011 at 20:52 UTC
Thanks for your response. What I don't understand is why is to so hard to give a more fine-grained locking support? In some sense, "lock" in my example takes an address (in some shared memory space) and puts a semaphore around it. Why should it be so hard to put a semaphore around the address space corresponding to the address space of the value of $h{$key}? Intuitively speaking, lock($h) and lock($h{$key}} both seem so similar in spirit.	[reply]

Replies are listed 'Best First'.

Re^2: Avoid Locking Entire Hashes
by jagan_1234 (Sexton) on Jun 13, 2011 at 20:52 UTC

Thanks for your response. What I don't understand is why is to so hard to give a more fine-grained locking support? In some sense, "lock" in my example takes an address (in some shared memory space) and puts a semaphore around it. Why should it be so hard to put a semaphore around the address space corresponding to the address space of the value of $h{$key}? Intuitively speaking, lock($h) and lock($h{$key}} both seem so similar in spirit.

[reply]