AWS FreeRTOS, task vs posix thread  - Page 1
Forum section: electronics / general

author: jnz
author_rank: Frequent Contributor
timestamp: March 24, 2019, 07:30:45 pm
content: While read AWS documentation I’ve spun myself around, could use assistance please!It seems to me that FreeRTOS is set to use tasks, which are separate and fully independent sections of software, they are controlled by the schedular and have their own stack/heap. These seem in the picture below to be APPLICATION, MQTT, and NETWORK.Then AWS/Amazon seem to heavily rely on ptheads. There is a flow example on this page that seems to show tasks and threads together:https://docs.aws.amazon.com/freertos/latest/lib-ref/html3/mqtt/mqtt_design.html1.Am I right to assume that tasks are separately managed and you need to expose global or external queues to get them to talk to each other as if they were separate cores - but that posix threads are basically just more like functions that share parent context?2.WHY? I guess I’m not seeing why they have pthread Send Queue vs just calling send_queue() like a loop style program would. Is it because pthreads can be interrupted to run another thread in the same context? If that is the case - is there a pthread schedular? Can you interrupt a thread and restore to it same point in context like a task?3.Am I right to assume that another possible use here is you could spool up zero to some dynamic number of threads where as functions that might be difficult? That in a big configurable and dynamic use software like this that might be why they chose threads for everything?

author: dmills
author_rank: Super Contributor
timestamp: March 25, 2019, 12:23:21 am
content: FreeRtos Task and Posix Thread are sort of the same thing, for all that the APIs are clearly very different.Generally all threads run in the same memory space but with seperate stacks (and sometimes some 'thread local' storage), this differs from Posix Processes that have separate virtual memory spaces.Both are tasks and threads scheduled and in kind of similar ways (FreeRtos using something akin to Posix SCHED_FIFO IIRC by default).In an RTOS a thread will only be preempted if another thread of higher priority becomes runnable rather then on a time slice expiring where a non realtime OS will happily preempt a thread for many different reasons.Generally the POSIX API is a Unix & Linux thing, it is not that well suited to doing proper realtime on tiny cores, which is why the FreeRtos interface is quite different. You would probably not use FreeRtos on a big iron host any more then you would run Linux on a M4, different tools for different jobs.

author: jnz
author_rank: Frequent Contributor
timestamp: March 25, 2019, 02:15:16 am
content: I’m sorry, I’m not following. Can you phrase that in terms of what Amazon is doing with their code?There is an issue that people seem to use task and thread words interchangeably, and in this case they are not. Are you saying each pthread in FreeRTOS has its own independent stack and runs off the same or a difference instance of a very similar scheduler as tasks?

author: rounin
author_rank: Regular Contributor
timestamp: March 25, 2019, 05:13:07 am
content: FreeRTOS tasks are are what pthreads would call threads. They all share a single heap, have their own independent stack, and share an address space. FreeRTOS tasks have strict priorities, since it is an RTOS, and you always ask for how much stack you want rather than usually using the default that pthreads picks for you but other than that they are about the same.

author: rounin
author_rank: Regular Contributor
timestamp: March 25, 2019, 05:19:29 am
content: Quote from: jnz on March 24, 2019, 07:30:45 pmTasks usually share some global queues. FreeRTOS cannot run on multiple cores (except for this one research project). Often you have an ISR push to a queue to unblock some tasks, or one task push to queues that other tasks use. Not true simultaneous processing, just allows for better code structure if you have a lot of asynchronous logically separated code.Quote from: jnz on March 24, 2019, 07:30:45 pmpthread's schedular is the linux kernel. threads and FreeRTOS tasks are synonymous. FreeRTOS's scheduler is part of the library, since all the code runs in "kernel mode", generally. Some ports run some code in user mode, but most of the time there is little difference between a task and the kernel.Quote from: jnz on March 24, 2019, 07:30:45 pmSometimes servers will spin up threads when clients connect, although this is not a scale-able practice.Threads (tasks) are nice when you want to write code that looks like it blocks, or wants to wait for stuff, and you have more than one thing to do, and you want to automatically do other things when they are ready to be done. And you don't want to poll, cause polling sucks.The kernel figures out what tasks /can/ be run, and runs those. It knows if someone is waiting for something, and doesn't waste time polling, if things are written correctly.

author: dmills
author_rank: Super Contributor
timestamp: March 25, 2019, 01:04:34 pm
content: A FreeRtos Task is more or less the same thing as a Posix Thread, just different nomenclature because one is an RTOS and one is a preemptive multi tasking OS with both Threads and Processes, people use the words interchangeably because they are interchangeable!In most cases all free rtos tasks share an address space, and you can use volatile globals (for example) for inter task communication, but the queue provided by the rtos has the advantage that it takes care of locking and blocking automatically.For example, I did a low speed serial thing where the UART interrupt read from and wrote to a couple of FreeRtos Queues, the next level up then just blocked on the uart RX queue and would be scheduled when something got added to that queue, when it had a complete valid command it would write the command and arguments into another Queue that would then be processed by my main application. Meanwhile other Tasks were doing DSP and driving the screen.I had something similar for I2C (which is notoriously slow), stuff a message into the queue and get un blocked once the exchange has happened, meanwhile other tasks continue to run.Nothing that could not be done with a super loop and state machines of course, but far more convenient to write, and (mostly) easier to reason about.One targets Posix is writing to run on a Unix type environment (AWS? Linux? BSD? Whatever), and Freertos when targeting the sort of platform where that makes sense (small embedded MIPS, ARM M4, that sort of thing).Posix also has Fork available, so separate Processes (Running in isolated address spaces) are a thing on that platform while they don't (usually) exist on the much lighter weight RTOS.Regards, Dan.

author: jnz
author_rank: Frequent Contributor
timestamp: March 26, 2019, 03:42:13 am
content: Great! Now that’s all fine and makes sense.Well... it still makes no sense why Amazon would add pthreads to their own FreeRTOS implementations. It’s not like they have MQTT client already written for POSIX in C that would come over ideally. But whatever, it’s a wrapper for tasks.Thanks guys

author: dmills
author_rank: Super Contributor
timestamp: March 26, 2019, 05:04:16 pm
content: But everyone and there dog knows how to do POSIX threads, bit like providing a BSD sockets interface for networking, there are other ways to do it, but everyone knows the sockets API.Sometimes a wrapper to expose a widely used API just makes sense. (And I bet there is an MQTT client in C that would port, not worth the trouble for one thing but possibly a big win if you think there is a lot of code that gets easier to port with a more POSIX style API).Regards, Dan.

author: ejeffrey
author_rank: Super Contributor
timestamp: March 26, 2019, 06:36:29 pm
content: I don't actually see any evidence in the documents you linked to that amazon uses pthreads in their IoT version of FreeRTOS, but it wouldn't be a bad idea for the reason dmills suggested. Rather it looks like they have their own very simple custom amazon API for threading and communication primitives, and they have implementations of those primitives on FreeRTOS (for microcontrollers) and on POSIX platforms. I think the idea here is to support models where you might have an IoT ecosystem that consists of lightweight devices with microcontrollers running FreeRTOS and zigbee, heavier weight gateways with wifi and running Linux, and android/ios apps to control them all. Amazon wants you to have all of those talk to AWS, and is trying to make it so that you can share application code between them.

author: dmills
author_rank: Super Contributor
timestamp: March 26, 2019, 06:46:58 pm
content: Yea, writing an OS abstraction layer makes sense from Amazons perspective, difficult to do really well however as the devil with that sort of thing is very much in the detail.The FreeRtos thread model is kind of nice in that you can run with no dynamic allocation, kind of nice in small embedded applictions, but it can be hard to really do with the POSIX API.My world does not use free RTOS for IOT crap so we don't really see that side of it in purely standalone applications.Regards, Dan.

author: andersm
author_rank: Super Contributor
timestamp: March 27, 2019, 07:56:36 am
content: Quote from: ejeffrey on March 26, 2019, 06:36:29 pmThey have alibrarythat implements some portion of the pthreads API on top of the native FreeRTOS API.