Feature request: expose hash table lock so that user can lock a hash table using get-mutex and release-mutex.

[Kevin Raison]

Feature request: expose hash table lock so that user can lock a hash table using get-mutex and release-mutex.

[Juho Snellman (jsnell+bugs)]

On Thu, Jan 20, 2011 at 12:04 AM, Kevin Raison <email address hidden> wrote:

> Feature request: expose hash table lock so that user can lock a hash
> table using get-mutex and release-mutex.
>

I'm not sure we want to expose the exact way in which the hash table is
synchronized, since that would then lock us to that implementation forever.
Is there something wrong with sb-ext:with-locked-hash-table?

--
Juho Snellman

[Kevin Raison (raison)]

sb-ext:with-locked-hash-table is great but it doesn't satisfy my
particular use case. I have a set of nested hash tables and a
transaction architecture that locks various tables within that
structure. This locking can occur in various places in the code, but
any given lock should always be held until the end of the transaction,
when all locks are released at once. The simplest way to accomplish
this would be to use the existing lock that is part of the hash-table
struct, locking each table as needed with get-mutex, pushing the lock
onto a list and then releasing all locks in the list at the end of the
transaction. I could of course create my own structure that includes a
hash table and a lock, but it seems wasteful to do so given that there
is already a lock created per hash table anyway. I definitely
understand why exposing the internals of synchronization is not a good
idea; so perhaps a set of compromise functions makes sense:

(acquire-hash-table-lock ht)
(release-hash-table-lock ht)

What do you think?

Thanks for taking the time to discuss this with me.

Cheers.
Kevin

On 01/19/2011 03:46 PM, Juho Snellman wrote:
> On Thu, Jan 20, 2011 at 12:04 AM, Kevin Raison<email address hidden>
> wrote:
>
>> Feature request: expose hash table lock so that user can lock a hash
>> table using get-mutex and release-mutex.
>>
>
> I'm not sure we want to expose the exact way in which the hash table is
> synchronized, since that would then lock us to that implementation forever.
> Is there something wrong with sb-ext:with-locked-hash-table?
>

[Attila Lendvai (attila-lendvai)]

the question here is whether sbcl maintainers want to advertise this functionality as public and be concerned about it in the future, or not.

if i were you i'd simply use the internals in this case, or maybe set up my own abstraction if i wanted to be portable...

[Kevin Raison (raison)]

Atilla, what you suggest makes sense to me. Without much digging, it seems like a reasonable implementation would look something like

(in-package #:sb-impl)

(export 'hash-table-spinlock)

(in-package #:sb-thread)

(export 'get-spinlock)
(export 'release-spinlock)

(in-package #:cl-user)

(defun acquire-hash-table-lock (hash-table)
  (sb-thread:get-spinlock (hash-table-spinlock hash-table)))

(defun release-hash-table-lock (hash-table)
  (sb-thread:release-spinlock (hash-table-spinlock hash-table)))

Thanks everyone for talking with me about this. I am happy to write my own interface as Attila suggests; I'll close the bug if no one else has anything to add.

Cheers.
Kevin