Re: [go-nuts] Advice on a thread-safe fetch-and-cache design

[Russ Cox]

The usual pattern is to have a lock around the cache and then have each entry be a pointer to a struct that can itself be locked. The lookup is then:

lock(cache)
if cache is missing entry:

    cache[key] = new entry

entry := cache[key]

unlock(cache)

lock(entry)

if entry is not populated:

    entry.val = compute()

val := entry.val

unlock(entry)

return val

It is true that you can create a goroutine and channel for every entry instead of putting a mutex in the entry. But putting the mutex in will be faster at run time and also have less overhead (a channel already contains a mutex, so sizeof(mutex) < sizeof(channel) + sizeof(goroutine) for sure).

Russ

[Michael Jones]

Don't forget, if you do that, to again check the status once you get into the critical section. It may have changed between your initial probe and the first code the return from acquiring the lock.

is missing? { lock; is missing? update; unlock }

On Tue, Feb 19, 2013 at 11:00 AM, <hjfr...@google.com> wrote:

Aww, this solution isn't as fancy, but it indeed seems like the right one. Thanks for the advice.

Quick general concurrency follow-up: it seems tempting to use a RWLock in this situation to do the check in read-only mode, then release and grab the write-lock if you actually do need to modify the state. Of course, this doubles the number of critical sections so it's a lot trickier to get right, but it seems like it'd have better performance if the cache usually doesn't change. Is it at all worth it to do it this way? (I'm assuming the answer is "it depends" but I'm wondering if you have a general opinion on the matter.)

Hunter

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1 650-335-5765