threadx | Azure RTOS ThreadX | Azure library

No, there's no difference in how you should build them, gcc -c works on either to produce a .o.

GCC handles the difference in pre-processing them or not.

Obviously your Makefile needs to have a rule to build a .o from a .s or .S. At the simplest, just duplicate the pattern rule for %.o: %.S, since it seems to be surprisingly inconvenient to define a case-insensitive pattern rule or simply list two possible patterns for one rule in the general case.

The lock coarsening (and reordering) is allowed because the synchronized readers either get ordered before or after the coarsened lock. They will never be able to see what is happening while the coarsened lock is held and hence can't observe any reordering inside the locked code.

For more information see: https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#myth-barriers-are-sane

Nice question btw. I was struggling with this particular example as well some time ago :)

1. The location of data for each module is determined at run-time. This is to allow loading the same module more than once, each instance having separate data, in different locations.

2. Globals are located in the data area. The modules are compiled as position independent code and position independent data. While loading the module the module startup code is provided with the load address of the data. The specifics of how this is achieved are different for each architecture and compiler.

Better create another function to create the Thread instance and start it:

This is by design, ThreadX is a small monolithic kernel, where application code is tightly integrated with the kernel and lives in the same address space and mode. This allows for greater performance and lower footprint. You can also use ThreadX Modules, where the available MPU or MMU is used to separate kernel and user code into different modes and provide additional protection, but this incurs a small performance and footprint penalty.

ThreadX is intended for devices much smaller than anything that runs Android; you must give up on the idea that there will be any debug facility incorporated in your target. With embedded devices, your debug capabilities are in the development tools which run on a Windows PC (and yes, most embedded tools only run on Windows) attached to the target. That said, there are excellent debug tools built into any embedded IDEs these days.

If you are interested in ThreadX, get a development board from Renesas that incorporates a debugger link. These are typically available for less than $50 USD. The Renesas IDE, E2Studio, has great support for ThreadX. I also understand that the watch from Pine64 runs ThreadX but I am awaiting that device's arrival and have not used the Nordic tools before so I can't say how well ThreadX is integrated into that.

Finally, and I have no vested interest in this, if you are starting in embedded code you might want to check out FreeRTOS instead of ThreadX. I can't say it is superior in any technical way; but, if you search here you'll see there is a much bigger community of FreeRTOS users than ThreadX. To me, they both work fine, its easier to find help with FreeRTOS as a quick search will reveal 10x the postings for FreeRTOS vs ThreadX.

Yes, the ARM and ARC ports are very different, i.e., different assembly code, pragmas, intrinsics, etc. It’s also noteworthy that different development tools are in play as well. For example, the main development tool for ARC is MetaWare (compiler/debugger), while on ARM there is IAR, ARM, GCC, etc.

As for stack backtrace, this is typically setup such that the debugger can create a call tree when there is a halt of execution or breakpoint in the current thread’s code. The backtrace byte pattern effectively represents the top of the stack and signals the debugger to stop building the call tree. Of course, this is every specific to the debugger and in this example the difference between the MetaWare debugger and the ARM tool debuggers. As for the 0xEF patter on the stack, this is useful for visual inspection by the developer. The pattern is also used by the run-time stack checking feature in ThreadX (please refer to the ThreadX User Guide documentation). Also, the IAR and MetaWare debuggers are able to calculate stack usage via examination of 0xEF pattern erosion in each thread’s stack and present that very useful information to the developer.

Azure RTOS THREADX does not require a bootloader itself and is in general bootloader agnostic. A typical use of Azure RTOS THREADX is to be linked and located as part of the application program in a device’s flash memory, where the entry point is tied to the reset vector. However, there are some applications that do require a bootloader. In such applications, Azure RTOS THREADX simply looks like the application code image so nothing special is required in THREADX. In either case, Azure RTOS THREADX doesn’t know or really care how it was loaded and thus stays out of the way of the application’s particular boot sequence needs.

I don't know the problem class nor the appropriate terminology

I'd probably just refer to the problem class as concurrent task orchestration.

There's a lot of things to consider when identifying the right approach. If you provide some more details, I'll try to update my answer with more color.

There are no constraints like "you must access B before you can do X with C" or similar.

This is generally a good thing. A very common cause of deadlocks is different threads acquiring the same locks in differing orders. E.g., thread 1 locks A then B while thread 2 owns the lock B and is waiting to acquire A. Designing the solution such that this situation does not occur is very important.

I couldn't find anything like SettableFuture in the JDK

Take a look at java.util.concurrent.CompletableFuture - this is probably what you want here. It exposes a blocking get() as well as a number of asynchronous completion callbacks such as thenAccept(Consumer).

invokeAndWait is generally considered prone to deadlock

It depends. If your calling thread isn't holding any locks that are going to be necessary for the execution of the Runnable you're submitting, you're probably okay. That said, if you can base your orchestration on asynchronous callbacks, you can instead use SwingUtilities.invokeLater(Runnable) - this will submit the execution of your Runnable on the Swing event loop without blocking the calling thread.

I would probably avoid creating a thread per singleton. Each running thread contributes some overhead and it's better to decouple the number of threads from your business logic. This will allow you to tune the software to different physical machines based on the number of cores, for example.

It sounds like you need each runWithX(...) method to be atomic. In other words, once one thread has begun accessing X, another thread cannot do so until the first thread is finished with its task step. If this is the case, then creating a lock object per singleton and insuring serial (rather than parallel) access is the right way to go. You can achieve this by wrapping the execution of closures that get submitted in your runWithX(...) methods in a synchronized Java code block. The code within the block is also referred to as the critical section or monitor region.

Another thing to consider is thread contention and order of execution. If two tasks both require access to X and task 1 gets submitted before task 2, is it a requirement that task 1's access to X occurs before task 2's? A requirement like that can complicate the design quite a bit and I would probably recommend a different approach than outlined above.

Is there a superior approach that I didn't consider?

These days there are frameworks out there for solving these types of problems. I'm specifically thinking of reactive streams and RxJava. While it is a very powerful framework, it also comes with a very steep learning curve. A lot of analysis and consideration should be done before adopting such a technology within an organization.

Update:

Based on your feedback, I think a CompletableFuture-based approach probably makes the most sense.

I'd create a helper class to orchestrate task step execution: