ngx.shared understsanding

[Alexis Okuwa]

Wanted to know i someone can go into depth about the ngx.shared so i know what its used for but the way the docs talk about its to be careful because its in the global space so wanted to know how the locking for this sort of thing works. Do reads block reads or do they just block writes does it block everything with in one shared space or just the element of the shared space. Would love to use something like this for some IPC like stuff but not sure how it works. 

[Yichun Zhang (agentzh)]

Hello!

It's a per-zone global lock. Readers block writers and other readers
atm. It's usually not a problem since there is usually NO syscalls or
I/O involved while holding the lock. (All most all the standard nginx
modules like ngx_limit_zone and ngx_limit_req use the same lock for
their shm zones).

Regards,
-agentzh

[Alexis Okuwa]

Are there any plans to have it lock per key and not a global lock, also is there anyway to have it to not block other readers.

[Yichun Zhang (agentzh)]

Hello!

On Thu, Aug 18, 2016 at 11:00 AM, Alexis Okuwa wrote:
> Are there any plans to have it lock per key and not a global lock, also is
> there anyway to have it to not block other readers.
>

We could introduce a readers-writer lock where multiple readers are
permitted traversing the red-black tree at the same time. But writes
might be delayed a bit more. Patches welcome.

Per-key locking that you proposed does make no sense to me since we
use data structures like red-black trees and linked lists.

I suggest you only try optimizing things that are shown in your on-CPU
and/or off-CPU flame graphs under realistic workload. Otherwise it's a
premature optimization that does you no good :) See

http://openresty.org/en/profiling.html

Regards,
-agentzh

[Shriram Rajagopalan]

So just to summarize, when I store a large table in ngx shared dict, reading or writing from table locks the entire table. This means that in my lua code i dont need explicit locking even if I have multiple workers in my nginx conf running the same lua code.
And if one of them updates the table, I dont have to worry about concurrency issues.

To double check, all this reading writing can happen on per request basis. Right?

That would simplify my code a lot.