Re: [riot-devel] tests compiler policy
Hi Gero, Thanks for tackling this! On 10/9/19 09:12, Gero Müller wrote: I have no idea about the performance / feature differences, but I use the vanilla version and it works fine. What about the C library/newlib? I know TI also provides newlib. Where would newlib come from if we used vanilla GCC? Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Porting Zenoh Protocol to RIOT
Hi Brenton, On 26/7/19 09:26, Brenton Chetty wrote: For compiling ZHe, i receive the following error "fatal error: netinet/in.h: No such file or directory, #include " ** The header is available: https://github.com/RIOT-OS/RIOT/blob/master/sys/posix/include/netinet/in.h To use it you must add "posix_headers" to USEMODULE. For compiling Zenoh-C, i receive the following error "Looking for pthread_create - not found" "-- Check if compiler accepts -pthread - no"Note, that pthread.h was found. The error you are receiving seems to come from the configure phase. AFAIK Riot's pthread support does not use the "-pthread" compiler flag so you should find a way to skip that check. Keep in mind Riot's Posix compatibility module is incomplete. There is a "pthread" module (add it to USEMODULE), but don't expect it to behave exactly like Posix mandates or to support everything. It all depends on how much of the functionality Zenoh-C needs (it may even compile but not work as intended). Also note, ZHe does not use threads, whilst Zenoh-C does use threads. Then I predict you might have more success with ZHe. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Lightweight Syslog Implementation
On 29/5/19 14:58, Robin wrote: The only problem i see is how the backend would distinguish between a message for serial logging and a message for something else like syslog, since both logging request would be done by invoking LOG(level,"message"). the "level" parameter of our current API is just a level. In unix, on the other hand, one has "priority". From the man page of syslog() > The priority argument is formed by ORing together a facility value and a level value (described below). The good news is that this ORing scheme is is compatible to what we are doing now (it is like we are currently defaulting facility to zero). On the other side of the message queue you will have: - The PID of the originating thread. In a way this means that "LOG_PID" is always on. - The (facility, level) selected for that message (can that live in the "type" field?) With that information an appropriate policy can be implemented. How is that policy specified and what is the policy is a matter that if think is better to ignore for now so that we don't make too many assumptions. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Lightweight Syslog Implementation
Robin, On 28/5/19 18:53, Robin wrote: Only problem here is that syslog as implemented in gLibc expects a user to issue a call to openlog first. Maybe I can make the call to openlog implicit and thus make it compatible to both API‘s. The standard works in our favor here: "The use of openlog() is optional" and " The use of closelog() is optional". We can have no-ops for both functions: #define openlog(ident, option, facility) (void)((ident), (option), (facility)) Another solution could be to extend the log module with a bootstrap/init function which defaults to do nothing in most cases. Should not be needed if we do what unix syslog does, initialize it on the first call to syslog() if necessary. One problem with the generic LOG approach that comes to my mind is that it looks like a all or nothing approach. I suggest the choice should not be between serial backend and syslog backend, but rather between serial backend (used for most simple applications) and IPC/message queue backend. At the end of the quie is the logic deciding how the packet should be sent. An advantage of this approach is that is is also useful for serial-only loggers where one wants to ensure strings don't intermingle. Also the current implementation of uart logging inherits the blocking characteristics of the UART, meanings that logging blocks until the message has been sent. Of course, most applications are fine with just writing directly to UART backend and having the queue by default would be overkill. When I implement the syslog implementation as a log module it wouldn’t be possible anymore for the user to decide which logs should be shipped via syslog and which logs only should be send over serial line. With a queue, the decision can be made according to the PID of the message sender. Or, even better, according to the facility value set by that thread in openlog(). BTW, there is an option in UNIX called LOG_CONS: > LOG_CONS Write directly to the system console if there is an error while sending to the system logger. The more we discuss this topic, the more I'm convinced we cannot overlook it if we want RIOT to be practical for large-scale deployments. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] RIOT vectors for Smartfusion2 port
Assim, Hauke, To comment a bit on Hauke's suggestion. On 29/5/19 08:47, Hauke Petersen wrote: The general approach for porting CPUs in RIOT is to rely as much as possible on shared code... That's very important, try to take advantage of what's already in RIOT. > . All the specific CPU implementations have to provide, are their interrupt vector structure (see e.g. `cpu/samd21/vectors.c` or `cpu/stm32f4/vectors.c`), Hauke, The SmartFusion is integrated is integrated into a FPGA, so the vectors can change depending on how one programs it (am I right, Assim?) It would be highly desirable if he does not have to translate the automatically generated assembly file into C. Specially considering it contains some platform-specific code (I see something about eSRAM EDAC and ECC mempory). I think this is the piece of code that introduces the dependency on vectors: https://github.com/RIOT-OS/RIOT/blob/7e3c382547430fae0a81e4f44c64d23e18629549/makefiles/arch/cortexm.inc.mk#L138 See the UNDEF. I may be wrong here, but I believe it is to prevent the symbols being dropped. What you can do is either: - Provide an empty vectors.c (to make the build system happy) AND add startup_m2sxxx.o to the UNDEF. - Add a rule to build vectors.o from startup_m2sxxx.S AND also make sure startup_m2sxxx.o does not get built. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Lightweight Syslog Implementation
On 24/5/19 11:40, Kaspar Schleiser wrote:
> IMO the syslog API itself should not be used for new or RIOT-targeting
applications...
Except it already is:
#define log_write(level, ...) printf(__VA_ARGS__)
and
static inline void log_write(unsigned level, const char *format, ...) {
While syslog has
void syslog(int priority, const char *format, ...);
So the existing log framework is almost the same as syslog, but with
different names (it makes sense, there are not that many ways of doing
logging.)
BTW, this thing can be quite useful when logging to serial: by having a
backend that sends logs as messages in a queue one can prevent messages
sent simultaneously from stepping over each other.
Regards,
Juan.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] How to properly use cortexm_sleep
Hi Kees, Some observations: 1- WFI will not send you to the deepest sleep states- clocks are gated, but many things remain powered. 2- If you are using the timer module and depending on you clock configuration you may experience more or less frequent wake ups. Whether this is acceptable is up to you. 3- Normally, if no thread is runnable (i.e. all are waiting/blocked) the idle thread is run and that has a loop which sends the MCU to the deepest state possible (considering the currently-enabled peripherals). This means that in many cases the explicit WFI is not needed if in your "while(forever)" loop you put some call that blocks waiting for the events you are interested in. The interaction between (1) and (3) means that by doing a WFI in a thread it is possible that you don't sleep as deep as you could: - The current thread will be blocked on the WFI instruction until an event arrives. - In the meantime, control will not go back to the kernel. - This means the idle thread will not run (from the schedulers point of view, you thread is still running). - The pm_whatever() call in the idle thread will not run. In conclusion, try to use the default mechanism if you can. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] FreeRTOS comparison in the website
Hi RIOT developers, In many of the meetings/events I have been with the RAPStore team we had quite a few people asking us how does RIOT relate to FreeRTOS. The "official" response up to now has been that we don't do that comparison because FreeRTOS does not include all the things that RIOT has, mainly networking (and drivers too.) Still, people ask the question and I'd like to give them an answer. Also, I don't know how accurate is the "no network" answer, especially since FreeRTOS was acquired by Amazon. I've never used FreeRTOS so I'd be grateful if anybody who knows could explain what's going on. Looking at http://riot-os.org/ I don't see any comparison to FreeRTOS either. It would be great to have it so we can point people to our website when they ask. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] sched_active_thread is a volatile pointer, but volatile is ignored
On 8/1/19 21:47, Kees Bakker wrote:
E.g.:
void msg_recv(...)
{
if (!sched_active_thread->waiters) {
// platform specific macro to suspend thread
}
thread_t *waiter = sched_active_thread->waiters;
// ...
}
(or similar)
My understanding of volatile back then was that the compiler could,
without volatile, assume that sched_active_thread->waiters equals NULL.
Well, in the example code, the compiler would just read
sched_active_thread->waiters
once and keep it in a register. If either sched_active_thread or waiters
can change in between the uses in that function you must declare some
things volatile.
Say you do something like this:
extern void f(void);
int x;
int test(void)
{
int y = x;
f();
return y+x;
}
Then the compiler, knowing nothing about "f()", _has_ to re-read x in
the return statement. This is because f() could possibly modify x. This
is a behavior in which we can rely, because it is needed even in single
threaded programs. This is what happens when the above snippet is
compiled with anything above -O0:
int test(void)
{
0: b538push{r3, r4, r5, lr}
int y = x;
2: 4c03ldr r4, [pc, #12] ; (10 )
4: 6825ldr r5, [r4, #0]
f();
6: f7ff fffe bl 0
return y+x;
a: 6820ldr r0, [r4, #0]
}
c: 4428add r0, r5
e: bd38pop {r3, r4, r5, pc}
10: .word 0x
See the two lines with "ldrrN, [r4, #0]".
In the provided example of "msg_recv", if the "platform specific macro
to suspend thread" includes a call to a function not defined in the
current translation unit, then the compiler cannot assume that this
function does not access or change globals. The only problem would be if
the compiler thinks he knows what the function does (via inline or LTO).
Looking at the code for _msg_receive() it does not seem to be the case,
to I'm puzzled as to why it would break. I tried removing it, and there
does not seem to be a problem. I'll PR it can be tried in the CI.
Marian,
> I think getting rid of `volatile` and adding "proper" memory barriers
to places
> where context switches are supposed to happen will make the code more
robust and
> might allow the compiler to optimize the code better
Yes, that should work in those cases where the compiler may think he is
sure a function call cannot modify certain variables. For example, the code:
int x;
int test2(void)
{
int y = x;
int k = z(x);
return y+x+k;
}
Gets turned into:
int z(int x)
{
return x*x;
}
14: fb00 f000 mul.w r0, r0, r0
18: 4770bx lr
001a :
int test2(void)
{
1a: b510push{r4, lr}
int y = x;
1c: 4b03ldr r3, [pc, #12] ; (2c )
1e: 681cldr r4, [r3, #0]
int k = z(x);
20: 4620mov r0, r4
22: f7ff fffe bl 14
return y+x+k;
}
26: eb00 0044 add.w r0, r0, r4, lsl #1
2a: bd10pop {r4, pc}
2c: .word 0x
I compile with -Og to prevent inlining. Observer that the global "x" is
only loaded once.
> `void __sync_synchronize(void)` placed just before and just after a
context...
Yes, but most likely overkill. __sync_synchronize() is meant to issue a
hardware barrier (that is, force the CPU to comlete all pending memory
operations.) This is needed in multi-core, and maybe some single-core
scenarios, but it is not what we are looking for. We need a _compiler
barrier_, like linux's barrier macro(). See this code:
int x;
int test3(void)
{
int y = x;
__sync_synchronize();
//__asm__ __volatile__("": : :"memory"); // linux's barrier()
return y + x;
}
With no barriers, the ASM shows that x is read once.
__sync_synchronize() inserts a "dmb" (data memory barrier) instruction
in addition to forcing an additional read:
int test3(void)
{
int y = x;
30: 4b03ldr r3, [pc, #12] ; (40 )
32: 6818ldr r0, [r3, #0]
__sync_synchronize();
34: f3bf 8f5b dmb ish
return y + x;
38: 681bldr r3, [r3, #0]
}
3a: 4418add r0, r3
3c: 4770bx lr
The other barrier causes a re-read, but without the "dmb", which is
probably what we want in most cases. Linus has a series on emails[1] in
which he explains why barrier() is good and essentially free.
Regards,
Juan.
[1] https://yarchive.net/comp/linux/compiler_barriers.html
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] USB PID number
Hi all, First of all, great work. Now to the VID, PID matter: I don't think we should get any VID. A single PID may be ok. Product numbers are for products. RIOT is not a product. Rather, it is used to build product (or at least that's wath we hope for). Even if we obtained an ID it would be irrelevant for everyone except developers: if you develop a device, you should get your OWN ids, you cannot reuse your OS vendor's. For example, I remember using TI's USB library for the MSP430 some years ago (horribly ugly, btw) and it does NOT come with any ID. > > My question is if anydbody has a better solution for the vid/pid > problem? If not wether anybody minds if I go ahead and fill out the > necessary info to request a PID from the pid.codes collection. > Quoting from PID.CODES: "If your project involves both hardware and software, both need to be licensed under recognised OSS and OSHW licenses. If your project involves only one or the other, we may ask for further justification as to why you need a PID associated with your software project / development board instead of allowing end-users to request their own." I think that having a single PID for "Generic RIOT-powered device" (or something of the sort) is valuable, especially for development, and for the CI, and we only really need one, not a whole block. That, and the fact that we have a more or less large project should be enough justification to get a PID from pid.codes. Of course, the docs should clearly state that the PID is for use in RIOT development and should be changed for actual devices. A whole VID would not be useful: what would you do with so many PIDs? Looking forward to the first riot-powered USB peripherals. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] sched_active_thread is a volatile pointer, but volatile is ignored
Hi Kees, On 1/4/19 10:18 PM, Kees Bakker wrote: In a lot of our code sched_active_thread is converted into a non-volatile pointer. Is that correct? Here [1] it is described that such conversion is undefined behavior. My understanding is that `sched_active_thread` is volatile in a thread context, but not in the kernel context. Therefore I thought that discarding the qualifier in code that runs in the scheduler should be OK, although a bit dirty. Now, if you tell me it's undefined behavior then it is NOT OK. I had thought of two ways to fix this: * Linker-level aliasing: define `sched_active_thread` once (in the scheduler, as non volatile) and declare it as `extern volatile` in those headers that are seen by user applications, and as `extern` in headers seen by the kernel. * C-level aliasing: redefine sched_active_thread as a union of a volatile and non-volatile. AFAICT neither of those ways of accessing should result in undefined behavior, as there as no casts being performed. What do you think? Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Compile-time peripheral configuration in board definitions
Hi Gunar, Even though these static const arrays are allocated in the .rodata segment, they are allocated in each module that includes `board.h`. XFAs addresses this problem. So you are saying that the data gets duploicated in ROM several times? I did not know that. If that is the case, then it's definitely a bad thing! For ESP32-Boards I tried another approach. In `periph_conf.h` there is only a declaration of an external const variable `pwm_dev_num` which contains the number of PWM devices and the macro `PWM_NUMOF` is then defined as follows: ``` extern const unsigned pwm_dev_num; #define PWM_NUMOF (pwm_dev_num) ``` Regardless of ROM duplication or not, I think you approach is much better and cleaner. Also, you don't bloat the header, and don't have the compiler parse the same definitions several times. I see no reasons to define the array in the header file. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Mutex and thread priority
Hi Baptiste, On 11/22/18 12:11 PM, Baptiste Clenet wrote: Hi, I have looked at mutex.c and thread.c and I've understood that a thread with higher priority (it has priority) will unlock the mutex even if thread with lower priority has not finished/unlock the mutex? Am I right? You are referring to a situation in which a thread unlocks a mutex it did not lock before? In that case the mutex is not behaving as such, but rather as a generic lock, and any thread can unlock it. See https://github.com/RIOT-OS/RIOT/issues/9594 . If you want the mutex to actually behave as a mutex you should ensure you never have an unlock without a matching lock (i.e. that the only thread that can unlock a mutex is the one that locked it and thus own it). RIOT's mutexes do not enforce that, so you must resolve it by careful usage. Now, in my case, I use UART with ethos (which use a mutex) and what happens on my case is: * I have thread A (high priority), thread B (low priority) * B starts to write on UART an long str * A wants to write on UART an lock the mutex (ethos) but because it has higher priority, it sends its message over UART until end of str * B can continue and finish to send its str So you are saying that the lower priority "B" thread is being preempted and it's output interrupted by A's output? I'm not familiar with ethos, but my intuition is that, while it may have a mutex, it may not be programmed in a way that the UART access is exclusive too. Exclusive access to UART would not be a good idea as in cases like yours it opens the door to priority inversions. So I'm wondering why a thread with higher priority should be able to unlock a mutex locked by a thread with lower priorty? Actually any thread can unlock a mutex locked by another thread. What can never happen is that a thread _locks_ a mutex locked by another thread. In your mind, replace the word "mutex" with "lock" and things may become clearer. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Cortex M33 support
On 10/17/18 4:19 PM, Alexandre Abadie wrote: Hi, Not M33, but Microchip is also selling an evaluation board with an M23. See https://uk.farnell.com/microchip/dm320205/kit-eval-xplained-pro-32-bits/dp/2901261 Alex PS: I'm not working on it. Excellent. The basic CPU support for box cortex should be roughly the same (something like "armv8_common"), am I right? I wonder how many of the new features are usable in RIOT. The stack limit seems interesting. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Cortex M33 support
Hi everyone, Is anybody working / wanting to work on Cortex M33 support? Currently there are no chips available for the general public. AFAICT Nordic and NXP are the only ones with pre-production parts. I'm trying to get samples from both. It would be great if we could have at least some basic support for when the devices reach the market. Also, if somebody has closer contact with either Nordic or NXP, it would be great. Regards, Juan Ignacio Carrano ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Git submodule in RIOT-OS/applications
Hi all, On 9/26/18 9:42 AM, Jose wrote: Does it make sense to provide a RIOT (git submodule) folder in the RIOT-OS/applications, pointing to the latest RIOT release? YES. - Applications will always be in a working state Yes. I think it is more important to have it in a working state than having them break because some external thing changed. That's what dependency pinning is about. - Might be easier for new users to clone and use And not have them scratching their heads trying to figure out why it does not work with the latest RIOT master. We would require to update the submodule at the end of a Release. Yes. But if we do things right, we should already be testing the apps after each release anyways, so it is not an additional burden. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Binding in Javascript
Hi Manar, On 9/26/18 12:12 PM, Manar Zaboub wrote: Hello, using the provided example[1] I was able to run Javascript engine (Jerryscript) on RIOT. I want to now bind additional functions to Javascript, for example to be able to start TCP communication using Javascript code. Great! We would greatly appreciate if you contributed the bindings. Can you please refer me to any examples or tutorials where binding functions in Javascript with RIOT is taking place? See https://github.com/RIOT-OS/RIOT/pull/7796/ . The PR is unmerged, but it contains what you are looking for. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Where to put board pictures?
Gunar, Joakim >> >> Would it also be possible with git-lfs to give the board developers >> access rights to upload pictures? >> With LFS it will work as with a regular file, and one would need to open a PR to add/change a picture. I would expect such PRs to be approved almost immediately. On 9/4/18 11:44 AM, Joakim Nohlgård wrote: Does git-lfs let the contributor include the pictures and other git-lfs blobs as part of a Github pull request? Yes. It even shows a preview. See https://help.github.com/articles/collaboration-with-git-large-file-storage/ Regards Juan ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Where to put board pictures?
Gunar, Jose > > In the end, it should not matter which git repository is bloated. > What about NO repository gets bloated? This was already discussed with some other maintainers offline, but I want to reinstate it here: We are not *special* in any way. Compared to other projects, RIOT OS does not have any crazy wacky requirements or limitations, and we are facing similar issues, for which- after similar sufferings- specialized tools were developed. Then why do we insist in doing things differently? I'm talking about git-lfs. This tools was invented to overcome all those issues we are mentioning in this thread. To me it is the only non-hacky solution. The only time a user will be exposed to the tool will be when building/editing the docs. git-lfs does not bloat the repo because binary blobs are not stored in there, and only the needed versions for the commits you are checking out are downloaded (not the entire diff history as with a regular text file.) Really, all this wiki-as-object-storage thing feels like hammering a nail with a screwdriver. If we go with the hacky solution we will regret it later when we have to maintain the mess. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Doxygen question for board/periph configuration header files
Hi Gunar, On 8/27/18 7:05 PM, Gunar Schorcht wrote: Hi, it seems that the style of the output changes either if a variable or function declaration is part of such group. But this is not always the case. For example, even though there are such declarations in http://riot-os.org/api/boards_2native_2include_2board_8h.html I find it useful to enable XML output in Doxygen and inspect the resulting XML. This will indicate if its a structure problem (meaning you messed up) or a rendering problem (meaning Doxygen messed up). In this case you are right, and the XML shows "LED Handlers" and "MTD emulation configuration" both correspond to `kind="user-defined">` elements, with no difference other than their contents. I think that what happens is that Doxygen presentation logic automatically detects groups with preprocessor definitions only and nests them under a "Macros" section. Unfortunately, there's not much that can be done to customize this behavior (see https://www.stack.nl/~dimitri/doxygen/manual/customize.html) Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Where to put board pictures?
On 8/21/18 4:23 PM, Jose wrote: The only issue is the fact git-lfs has to be installed in order to interact with the files (commands like `make doc`) won't pick the images because they will be sort of symlinks. Most users don't run make doc. It's run by the static checks, but only to verify docstrings are OK. In that case, we can ignore warnings caused by the missing images (option A). Another option is to instruct users to sync the LFS (B), or to do it automatically (C). I like (B) better. Regards Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Where to put board pictures?
On 08/21/2018 11:28 AM, Jose wrote: I personally think 2. (put them in the RIOT wiki) is the fastest way to go and doesn't bloat the RIOT repository. But I would like to hear some comments about this topic. If we put them in the RIOT wiki we can always choose to move them to the repo if it proves problematic. The other way round (moving them out of the repo) will leave a permanent blob in git's history. How about git-lfs? WRT another doc repo, I think documentation and code belong together. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Message queue that is not bound to a reveiving thread
Hi Gunar, A semaphore is a common way of implementing that. The semaphore value is the current number of elements in the queue. Reading from the queue is: semaphore s, mutex m, element e, queue q sem_wait(s) /* Blocks only if the queue is empty */ mutex_lock(m) e = queue_pop_left(q) mutex_unlock() Writing consists of mutex_lock(m) queue_push(q, e) mutex_unlock(m) sem_post(s) The mechanism is a bit more complicated if one needs to handle the case where the queue can be full and one wants to block. Also note that between the call to sem_wait() and mutex_lock() another thread could lock the mutex. This is not a problem. It only means that the second thread to wake up gets the first element the first gets the second. Something similar happens when one is writing. Each mutex already has a queue of threads waiting for it, meaning that if multiple threads are blocked on mutex_lock, the first one should be woken up by mutex_unlock, and "sema" implements semaphores on top of mutexes, so they should behave similarly. I'm curious as to the application of this, since RIOT does not run on multiple processor systems, what is the advantage of this approach over serial processing in a single thread (other than bypassing blocking calls). Regards, Juan. On 07/12/2018 09:58 AM, Gunar Schorcht wrote: Hi, what would be the best way, if there is one, to use the existing mechanisms to implement a message queue that is not bound to the receiving thread? What I'm looking for is a message queue that can be used by a number of threads to send messages to and receive messages from the shared queue, as it is possible in FreeRTOS, for example. Regards Gunar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Scheduler: Supporting Cooperative Threading
Hello Rioters, I'm trying to figure out how could cooperative multithreading / fibers / coroutines be used in RIOT. There is something already in the scheduler, but right now it looks more like an artifact of the implementation than a proper feature. Why --- Pre-emptive threading is hard to reason about, requires locks and synchronization and often there is no real need for pre-emption. With coroutines, on the other hand, the programmer knows his program wont be interrupted and resumed in any random line, but exactly when he chooses. It also means he does not need to synchronize access to resources shared with other coroutines. Coroutines make it possible to program asynchronous code in a blocking style - see "await". This is more natural and easier that using callbacks. Current state in RIOT - The current RIOT scheduler will only switch between threads with the same priority if there is an explicit yield, or if there occurs a preemption by a higher priority thread. This is almost cooperative multithreading (within the same "priority group"), except there is no guarantee that after a thread in a group is preempted, it will be that thread an not another with the same priority that will get resumed. Maybe that is the current behavior, but I'm having some trouble understanding the scheduler code. Also, the docs explicitly discourage the user from creating threads with the same priority. From "thread.h": > Assigning the same priority to two or more threads is usually not a > good idea. Starting point -- A good starting point would be to guarantee threads with the same priority get cooperatively scheduled 100% of the time. This means that if one thread is preempted by a higher priority task, then no other thread but that one will get resumed. In other words, the only way to switch between threads with the same priority is explicitly yielding from one. Maybe this is the current behavior. As I mentioned, I don't quite understand the code. Further development --- Coroutines / Fibers do not have to be full fledged threads. The TCB can be simpler and some objects can be shared with other fibers. See the PR on a thread-safe implementation of newlib (https://github.com/RIOT-OS/RIOT/pull/8619) for an idea of the overhead that thread-safety imposes. What is the general opinion on this? Is it work pursuing? I look forward to you feedback. Regards, Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Unimplemented syscalls in RIOT
Hello RIOTers, I have run into some issues while working on lua support, involving missing system calls and linker errors while trying to use C standard functions, such as rename() and clock(). For example: A program calls rename(). Rename is defined by newlib and calls link(), which calls _link_r (the reentrant version), which is not defined, so linking fails. A similar thing happens with clock() (calls times() which calls _times_r). The immediate reason is that, as of PR #8795, RIOT is linked with -lnosys, meaning newlib no longer provide stubs. Of course, for us this is a good thing (that's why the PR got merged). The problems arise when we try to compile packages, that is, code that we don't "control" and that we'd like to modify as little as possible. sys/newlib_syscalls_default/syscalls.c implements several stubs. For some functions it implements the right thing if the correct module is enable, like filesystem calls if we have VFS. There are several options for fixing this problem of missing syscalls: 1. Patch the packages to avoid those functions. It's a lot of work, and does not add any value to RIOT. 2. Add empty stubs that always fail (and set errno to ENOSYS). This makes programs compile, but then it may run into errors at runtime and the developer will be probably unaware that the code is using unsupported functionality. 3. Add empty stubs as part of a module, so that the fake functions must be explicitly included. 4. Make other riot modules provide the standard C interface. For example, xtimer may provide for clock(). Going back to my case of Lua, I initially thought of doing (2), but after a conversation with José Alamos he convinced me it's not a good idea. I'd suggest doing (3) and (4), that is, having parts of the standard library be implemented by the relevant RIOT module (clock() in xtimer, link()/rename() in vfs) while also having a stub modules for those cases in which it is acceptable to have unimplemented functionality. I look forward to you comments. Regards Juan. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
