Enhancement - CSPlike channels

[Bazmundi]

Since Lua-RTOS has tasks it would make sense to look at CSP like channels.

Starting postion might be LuaCSP perhaps. Or perhaps go like lua-channels.

[jolivepetrus]

@Bazmundi,

Lua RTOS is a multi-thread Lua environment, which means that Lua scripts can run on multiple threads sharing the global state, so a global variable can be shared by multiple threads, and special Lua libraries are provided to protect concurrent access and synchronise threads:

• Mutual exclusion functions
• Events

This is slightly different from other Lua concurrent approaches based on processes, in which each process runs a single-threaded Lua instance, each one with its own Lua state. In this approach, a communication mechanism between Lua instances is required to interchange data, because processes are isolated.

As far I can see, I'm not sure about the benefits of introducing a channel communication mechanism in Lua RTOS to share data between threads, because introduces an unnecessary overhead.

[Bazmundi]

go lang site suggests: In general use channels when Goroutines need to communicate with each other and mutexes when only one Goroutine should access the critical section of code. So, it depends on use cases. Events don't fit this use case in the absence of a payload. A payload on events might be of limited use. If you are suggesting global variables with an event and mutexes to act as a "channel" mechanism then you have your argument for channels.

…

On Mon, Oct 8, 2018 at 9:08 AM Jaume Olivé Petrus ***@***.***> wrote: @Bazmundi <https://github.com/Bazmundi>, Lua RTOS is a multi-thread Lua environment, which means that Lua scripts can run on multiple threads sharing the global state, so a global variable can be shared by multiple threads, and special Lua libraries are provided to protect concurrent access and synchronise threads: - Mutual exclusion functions <https://github.com/whitecatboard/Lua-RTOS-ESP32/wiki/Thread-Module#mutual-exclusion-functions> - Events <https://github.com/whitecatboard/Lua-RTOS-ESP32/wiki/EVENT-module> This is slightly different from other Lua concurrent approaches based on processes, in which each process runs a single-threaded Lua instance, each one with its own Lua state. In this approach, a communication mechanism between Lua instances is required to interchange data, because processes are isolated. As far I can see, I'm not sure about the benefits of introducing a channel communication mechanism in Lua RTOS to share data between threads, because introduces a unnecessary overhead. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#199 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABsMK2K3RTBKMi06TKv5u5RJGc_iTJ6Gks5uioJWgaJpZM4XKJNv> .

[Bazmundi]

A more detailed discussion is at: http://www.flounder.com/no_synchronization.htm On Mon, Oct 8, 2018 at 6:14 PM Asterion Daedalus < [email protected]> wrote:

…

go lang site suggests: In general use channels when Goroutines need to communicate with each other and mutexes when only one Goroutine should access the critical section of code. So, it depends on use cases. Events don't fit this use case in the absence of a payload. A payload on events might be of limited use. If you are suggesting global variables with an event and mutexes to act as a "channel" mechanism then you have your argument for channels. On Mon, Oct 8, 2018 at 9:08 AM Jaume Olivé Petrus < ***@***.***> wrote: > @Bazmundi <https://github.com/Bazmundi>, > > Lua RTOS is a multi-thread Lua environment, which means that Lua scripts > can run on multiple threads sharing the global state, so a global variable > can be shared by multiple threads, and special Lua libraries are provided > to protect concurrent access and synchronise threads: > > - Mutual exclusion functions > <https://github.com/whitecatboard/Lua-RTOS-ESP32/wiki/Thread-Module#mutual-exclusion-functions> > - Events > <https://github.com/whitecatboard/Lua-RTOS-ESP32/wiki/EVENT-module> > > This is slightly different from other Lua concurrent approaches based on > processes, in which each process runs a single-threaded Lua instance, each > one with its own Lua state. In this approach, a communication mechanism > between Lua instances is required to interchange data, because processes > are isolated. > > As far I can see, I'm not sure about the benefits of introducing a > channel communication mechanism in Lua RTOS to share data between threads, > because introduces a unnecessary overhead. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#199 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABsMK2K3RTBKMi06TKv5u5RJGc_iTJ6Gks5uioJWgaJpZM4XKJNv> > . >

[Bazmundi]

If it helps, even Kotlin has gone for channels.

[rosarioculmone]

Events can be used to synchronize two tasks. For example between producer and consumer for the management of a buffer but I cannot use them. Have any of you tried them?

[Bazmundi]

Events are not channels.

…

On Thu, 5 Nov. 2020, 02:25 rosarioculmone, ***@***.***> wrote: Events can be used to synchronize two tasks. For example between producer and consumer for the management of a buffer but I cannot use them. Have any of you tried them? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#199 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANQYK34FGQAM7THJTFM3CTSOF2QVANCNFSM4FZISNXQ> .