peterbourgon / diskv

A disk-backed key-value store.
http://godoc.org/github.com/peterbourgon/diskv
MIT License
1.41k stars 102 forks source link

Diskv concurrent access for read-modify-write cycle #25

Closed zserge closed 9 years ago

zserge commented 9 years ago

Diskv looks like a nice storage with good performance and simple API, thanks for writing it!

I'm looking for a simple+fast way to update a value in the store. Say, I want to read my object from the store, modify some of its properties and write it back. I want this whole sequence to be goroutine-safe so only one thread could modify the object at a time. And ideally I'd prefer not to use a single global lock. What would you recommend?

As for the global lock - I may use multiple diskv instances (like a pool) and for each key find a suitable instance first, then lock/unlock it. I see that Diskv structure already has a mutex (which is public) and that mutex is used internally to synchronize reads and writes. Since Go mutex is not reentrant - I think it's somewhat unsafe to expose this mutex. Am I right, that despite of being public - I should not use that mutex to lock/unlock Diskv instance?

peterbourgon commented 9 years ago

Cheers!

To your first point, diskv deliberately punts on anything more sophisticated that simple read-thru caching, including things like transactional synchronization. So for the behavior you want, I'd suggest writing a TransactionalDiskv wrapper, which would synchronize at whatever granularity you wanted (could be global, could be per-key) and serialize your compare-and-set operations that way. Make sense? If you made it reasonably generic, maybe it would make a good subpackage (github.com/peterbourgon/diskv/transactional or something) — if you felt up for a PR :)

Second, yes, it's an oversight that the mutex is public. I'll privatize it.

Thanks for the feedback! Let me know...