fix: struct PubSub isn't concurrency-safe

[fukua95]

Close #3021

[ndyakov]

@fukua95 thank you, looks good to me. I do think we can use RWMutex here, WDYT?

[derwesx]

I don't think this solves the problem in issue #3021 . It was about converting channel to string in logging, not PubSub.

pubsub.go -> initMsgChan:666

internal.Logger.Printf(
	ctx, "redis: %s channel is full for %s (message is dropped)",
	c, c.chanSendTimeout)

But surely, it solves potential issues with the same conversion of PubSub.

[fukua95]

@fukua95 thank you, looks good to me. I do think we can use RWMutex here, WDYT?

I also think using RWMutex for PubSub here is better. Would you prefer us to make this change in the current PR, or should we create a new PR for this modification?

[fukua95]

I don't think this solves the problem in issue #3021 . It was about converting channel to string in logging, not PubSub.

pubsub.go -> initMsgChan:666

internal.Logger.Printf(
	ctx, "redis: %s channel is full for %s (message is dropped)",
	c, c.chanSendTimeout)

But surely, it solves potential issues with the same conversion of PubSub.

Type chan is concurrency-safe, so if PubSub is concurrency-safe, we can safely perform read operations on a channel.

[derwesx]

Type chan is concurrency-safe

Yep, forgot that maps are in PubSub, then the issue is closed.

I do think we can use RWMutex here

// Slow
RWMutex_WriteOnly             7894350            177.0 ns/op
Mutex_Write 90%               9414898            150.6 ns/op
Mutex_Read 90%                8026020            146.4 ns/op
Mutex_WriteOnly               8143431            131.1 ns/op
RWMutex_Read 90%              8949892            117.9 ns/op
RWMutex_Write 90%             10608944           105.6 ns/op
// Fast

I doubt if the Read/Write coefficient is high enough to make RWMutex worth (Almost every methods modifies something, thus RLock will only help with Printf'ing).

[ndyakov]

@derwesx , @fukua95 if you are interested in this, we can merge the PR as it is and preform benchmarks for the locks in the future. Feel free to ping me anytime, I would love to see if we can squeeze a little bit more performance from the locking in general.