[FEATURE] AsyncKeyedLock

[MarkCiliaVincenti]

I am the author of the AsyncKeyedLock library and I believe that this library would benefit from depending on it. If you're interested, I can make a PR.

[jodydonetti]

Hi @MarkCiliaVincenti and thanks for your suggestion.

I took a quick look at your library and it's interesting, but FusionCache already has a similar mechanism in the form of various implementations of what I called a core "reactor".

The base abstraction is the IFusionCacheReactor interface which models a way to acquire/release a lock, with support for both sync and async programming models, timeouts, etc: you can see here I've been playing from the very beginning with different implementations, one of which (the "standard") uses a very similar technique as yours.

Currently I've yet to open up the whole reactor thing to the public: I mean, the source is of course already available (not all of them), but I'm not currently exposing the various impls as public because it's an area still under active research with a couple more experiments I'm doing on a separate local branch offline, not yet ready to share.

Can you point me to a potential advantage in using your lib?

Thanks!

[jodydonetti]

Closing for now since there has not been a response.
Will reopen in case something new will came up.

[MarkCiliaVincenti]

Hi, I saw https://github.com/ZiggyCreatures/FusionCache/blob/main/src/ZiggyCreatures.FusionCache/Reactors/FusionCacheReactorUnboundedWithPool.cs now

The library is more or less the same techniques. I'm surprised though why you used striping for the pool and then still used a dictionary. Why not just use lock striping? https://github.com/MarkCiliaVincenti/AsyncKeyedLock/blob/master/AsyncKeyedLock/StripedAsyncKeyedLocker.cs

[jodydonetti]

Hi @MarkCiliaVincenti , the specific reactor you pointed at (unbounded with pool) is not using a lock striping approach: it is using a normal dictionary (not a concurrent one) with a semaphore-per-key (so 1:1, not striped).

The small lock pool you see is there just to access the semaphore dictionary when it's time to add a new one, instead of using a concurrent dictionary (and after an initial read phase, so the classic double-checked locking).

It is just one of the many experiments I've played with here and there, and not the real one currently used inside FusionCache.

[MarkCiliaVincenti]

@jodydonetti, AsyncKeyedLock has matured since we last discussed and you may be interested in adding a dependency to it. I can help with this if you're interested.

[jodydonetti]

Hi @MarkCiliaVincenti , I have some good news about this!

Since I'm about to get to the big v1.0 release, I'm also finally opening up the internals related to the locking part: because of this with the next release you'll be able to create your own implementation of the memory lock and provide that as a third-party package, just like an implementation of a backplane or something like that.

In this way users will be able to pick and choose whichever they prefer.

Makes sense? Hope you like this.

Will update soon with some details.

[MarkCiliaVincenti]

I'm not entirely sure what you mean Jody. Do you need some changes to the PR?

[MarkCiliaVincenti]

Ah I think I get it now. But that would mean needing to create my own package if I understand correctly, or will it be an official FusionCache package which you'd link to from a readme where you explain pros and cons?

[jodydonetti]

I'm not entirely sure what you mean Jody. Do you need some changes to the PR?

Wait, which PR? Is there one?

[jodydonetti]

Ah I think I get it now. But that would mean needing to create my own package if I understand correctly, or will it be an official FusionCache package which you'd link to from a readme where you explain pros and cons?

I thought about you creating your own package, just because I thought you would've preferred to do that to have control.
Having said that, I can even create it myself like the serialization adapters I already created for the common serialization libs, no worries.

I'll update you soon then.

[jodydonetti]

Hi @MarkCiliaVincenti , I just release v0.25.0 🥳

It is now possible to create custom IFusionCacheMemoryLocker designs and implementations, like one with your own AsyncKeyedLock.

I quickly tried to create one and benchmarked it, with these results:

Method	FactoryDurationMs	Accessors	KeysCount	Rounds	Mean	Error	StdDev	P95	Ratio	RatioSD	Gen0	Gen1	Gen2	Allocated	Alloc Ratio
FusionCache	100	10	100	1	108.3 ms	0.43 ms	0.40 ms	108.8 ms	1.00	0.00	-	-	-	1773.63 KB	1.00
FusionCacheAsyncKeyedLocker	100	10	100	1	108.2 ms	0.37 ms	0.34 ms	108.6 ms	1.00	0.01	-	-	-	1558.52 KB	0.88
FusionCache	100	10	100	10	108.7 ms	0.59 ms	0.55 ms	109.5 ms	1.00	0.00	400.0000	200.0000	-	6375.15 KB	1.00
FusionCacheAsyncKeyedLocker	100	10	100	10	108.7 ms	0.43 ms	0.40 ms	109.1 ms	1.00	0.01	400.0000	200.0000	-	6165.36 KB	0.97
FusionCache	100	1000	100	1	231.7 ms	4.63 ms	7.87 ms	244.7 ms	1.00	0.00	10000.0000	9000.0000	1000.0000	112276.46 KB	1.00
FusionCacheAsyncKeyedLocker	100	1000	100	1	244.2 ms	4.84 ms	10.92 ms	261.5 ms	1.06	0.06	11000.0000	10000.0000	1000.0000	123452.45 KB	1.10
FusionCache	100	1000	100	10	507.8 ms	10.04 ms	25.38 ms	542.0 ms	1.00	0.00	34000.0000	23000.0000	6000.0000	393337.04 KB	1.00
FusionCacheAsyncKeyedLocker	100	1000	100	10	534.0 ms	14.71 ms	43.38 ms	592.5 ms	1.06	0.11	34000.0000	23000.0000	5000.0000	403604.58 KB	1.03

As you can see the numbers are roughly the same (I've used the standard one, not the striped), and with higher numbers of keys, accessors and so on it's using a little more resources so I don't feel like taking the extra burden of creating and maintaining a separated package myself.

Having said that you are now free to play with it if interested, and maybe come up with an even better one.

Thanks!