What is need for Read lock in Get()
hackintoshrao opened this issue · 4 comments
https://github.com/gorilla/context/blob/master/context.go#L31 ,
What is the need for read lock in GET() , how will simultaneous read effect the variables ?? In write, the lock makes sense , otherwise there is a chance for a goroutine to see a inconsistent view ..
What i want to understand why is the lock implemented in Get() ?
The read lock is needed to make sure that a write won't
change/mutate/delete the data you're trying to Get().
Note that the mutexes here contribute very little overhead to request
processing even under a fair bit of concurrency.
On Mon, 31 Aug 2015 at 7:51 pm karthic rao notifications@github.com wrote:
—
Reply to this email directly or view it on GitHub
#24.
Fair point . But if i'm writing only once during the initialization and then i just do Get() for rest of the lifetime of the program , then removal of lock in the Get() shouldnt make any difference right ?
Possibly. That's a big assumption to make—there are certainly cases where
you might (or other middleware using gorilla/context) might write to the
map more than once during a request.
I wouldn't remove the read lock unless you're positive it's going to make a
difference. I've benchmarked mutexes, spinlocks, no locks, etc and the
reality is that the difference in a networked HTTP application becomes
immeasurable compared to talking to a database or even just rendering JSON.
On Mon, Aug 31, 2015 at 8:08 PM karthic rao notifications@github.com
wrote:
Fair point . But if i'm writing only once during the initialization and
then i just do Get() for rest of the lifetime of the program , then removal
of lock in the Get() shouldnt make any difference right ?—
Reply to this email directly or view it on GitHub
#24 (comment).
That makes sense . Thank you ...