Using Locks Instead Of ExitGames.Concurrency
Options
Hey I was just looking at Lite src code for examples of where you might of used the retlang equivalent for concurrency that exitgames implements but instead I noticed that you guys use locks. Was this a design choice because Lite is fairly simple and most people who start out learning concurrency would be familiar with locks? Would it be possible to make use of a PoolFiber in the RoomCacheBase class instead of locks or is there something that makes locks more suitable in this case.
Do you guys know any quick locations of good examples of where retlang was used? If not I'll just slowly search my way through each source code example (which I'll probably do anyway). I've been looking at retlang and I think I understand some of it but I would still like to see multiple examples. I plan on doing something like adding a fiber to each publicly reachable (anywhere where concurrency issues may occur) data structure. Is that how retlang is supposed to be used? Because I don't really seem to be making use of the message passing abilities. I'm just planning on making a queue for each structure that is handled sequentially and uses the thread pool for scalability.
I think it's still better than locks because I won't hang up on anything, I'll just add it to the queue (fiber) and move on to whatever else I need to do and as long as the queue (fiber) doesn't overflow, I can just trust it to update the data structure.
Thanks for any clarification you could offer
Do you guys know any quick locations of good examples of where retlang was used? If not I'll just slowly search my way through each source code example (which I'll probably do anyway). I've been looking at retlang and I think I understand some of it but I would still like to see multiple examples. I plan on doing something like adding a fiber to each publicly reachable (anywhere where concurrency issues may occur) data structure. Is that how retlang is supposed to be used? Because I don't really seem to be making use of the message passing abilities. I'm just planning on making a queue for each structure that is handled sequentially and uses the thread pool for scalability.
I think it's still better than locks because I won't hang up on anything, I'll just add it to the queue (fiber) and move on to whatever else I need to do and as long as the queue (fiber) doesn't overflow, I can just trust it to update the data structure.
Thanks for any clarification you could offer
0
Comments
-
Well, when you have some expirience, you will understand this.
right now, i can say next. We use lock for synchronization and because we want work to be done immediately. this solution is more suitable us we think in this case
if for you enqueing fiber task is tataly good, go ahead0
