Named RW-Mutex? Other structure?

[Slawomir Pryczek]

Hi Guys,

what you think should be appropriate structure for asynchronous key/value store implementation, basically i want to be able to allow multiple reads/single writer per KEY...

Example below

 Operation; Key; Value

GET; counter;

SET; counter; 1

SET; counter; 10

GET; counter;

GET; counter;

SET; counter_xx; 11

GET; counter_u

SET: counter_u; ABC

GET; counter;

So how it should work...

Thread 1 will read counter

Thread 2 will write counter_xx

Thread 3 will read counter_u

---- SYNCHRONIZATION POINT

Thread 1 will write counter = 1

Thread 2 will write counter_u = ABC

---- SYNCHRONIZATION POINT

Thread 1 will write counter = 10

---- SYNCHRONIZATION POINT

Thread 1 will read counter

Thread 2 will read counter

Thread 3 will read counter

... basicall reading and writing of one key cannot occur at the same time...

I have 2 ideas... 

1. Implement named RW mutex, so it'll be some pseudo-code like this

if is_writing(operation) {

 lock_for_writing(key);

 ....

 unlock_w(key)

} else {

 lock_for_reading(key);

 ....

 unlock_r(key)

}

2. Second idea is to start eg. 20 go threads, with 20 channels, and send key to one of the threads, by MODULO of CRC of name... but then reads for hot keys would become single threaded.

Any more go-like concurrency pattern that's appropriate for this case. What you think?

Thanks.

[Steven Blenkinsop]

Does sync.RWMutex not do what you want?

https://golang.org/pkg/sync/#RWMutex

--
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/d/optout.

[Slawomir Pryczek]

Yes, it does what's needed however keeping separated mutex for each key doesn't seem very optimal... thought there's some better way of doing named rw mutexes when you need a lot of them...

[Shawn Milochik]

On Sun, Feb 7, 2016 at 12:34 AM, Slawomir Pryczek <slawe...@gmail.com> wrote:

Yes, it does what's needed however keeping separated mutex for each key doesn't seem very optimal... thought there's some better way of doing named rw mutexes when you need a lot of them...

You can use a single mutex for as many things as you want. The mutex doesn't actually do anything to the variable. As long as all your code properly uses the mutex then you won't have race issues.

You can also create a struct containing your variables and a mutex, which makes it clear to the anyone reading the code what the mutex is supposed to do.

Depending on which variables are accessed, how often, and how often they're written to (as opposed to only read), multiple mutexes may make sense to avoid a lot of waiting to acquire the lock.

[Andrew Bursavich]

Here's an example of a striped map, which may be what you're looking for. It does a lot of what you want and is still pretty simple: https://play.golang.org/p/oh1mmVuDx6

Cheers,

Andy