Critical sections enabled outside of the context of a reactor

[edwardalee]

This PR makes it possible for users to enter and exit critical sections and access time both inside and outside of the context of a reactor. This enables resurrecting the MQTT examples in the example repo.

This has a companion PR in lingua-franca.

[petervdonovan]

My understanding is that one of the key objectives of LF is to allow users to avoid the explicit use of mutexes/critical sections.

I assume that the MQTT example that you refer to is this file, where a mutex is acquired while accessing the MQTT API because the MQTT API is not thread-safe. If this is the case, then why not enforce mutual exclusion of accesses to the MQTT API by requiring all accesses to the MQTT API to be performed within the same reactor instance?

In order for this approach to work, it would be necessary for reactors to pass various arguments along to the MQTT reactor, and the MQTT reactor would have to pass back any handles and outputs that it gets from the API, and everything would have to be wired to that one reactor, and altogether it would make for a cumbersome way to access a simple C API. Furthermore, we would need some way of specifying that a reactor can only be instantiated once, which will be a nontrivial problem to solve at compile time in the presence of mutations or recursive instantiation with modal models.

However, I think that we should consider this approach anyway because doing so would draw attention to the areas where the LF language could be improved. If the standard way of using LF is to use it to structure an application but to resort to explicit critical sections as soon as it becomes inconvenient to use LF to avoid concurrency bugs, then LF applications will not be safer than applications written in popular general-purpose languages.

[erlingrj]

I agree with what you are writing, @petervdonovan. But there might still be reasons for exposing the platform API to the users. They might want to synchronize an async context in a lf_thread_t with either another lf_thread_t or with a reactor. We earlier had some debate on this here: #161

[petervdonovan]

OK, I will not belabor a point that has already been discussed. I am satisfied with having commented that the particular use of critical sections in the MQTT examples may not be appropriate.

[edwardalee]

I think @petervdonovan 's suggestion regarding MQTT is a really good one and it may not be all that hard to implement. But I also agree with @erlingrj that at least having the possibility of accessing those functions is OK. We don't have to encourage it, but might lead to some interesting innovations. Maybe @petervdonovan could open an issue in the examples repo to redesign the MQTT code?