-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancement - CSPlike channels #199
Comments
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: 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. |
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>
.
|
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>
> .
>
|
If it helps, even Kotlin has gone for channels. |
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? |
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>
.
|
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.
The text was updated successfully, but these errors were encountered: