⚙️ RTOS Fundamentals Vocabulary
5 exercises on core RTOS terminology: task, scheduler, preemptive scheduling, priority inversion, and priority ceiling protocol. Advanced
0 / 41 completed
1 / 41
Your team lead says: "Each task in our RTOS gets its own stack and runs independently."
What is a task in an RTOS context?
What is a task in an RTOS context?
Correct: B. In RTOS terminology, a task (also called a thread in some RTOSes) is a self-contained, schedulable unit of execution. Each task has its own stack, program counter, and priority. The RTOS kernel switches the CPU between tasks based on their priorities and states.
| Term | Meaning |
|---|---|
| Task / Thread | Independent execution unit with its own stack and priority |
| Task states | Running, Ready, Blocked, Suspended |
| Context switch | Saving one task's state and restoring another's |
2 / 41
A colleague explains: "The scheduler decided to preempt Task A because Task B became ready."
What is the scheduler in an RTOS?
What is the scheduler in an RTOS?
Correct: B. The scheduler is the heart of the RTOS kernel. It runs on every context-switch trigger (tick, interrupt, or task state change) and applies a scheduling algorithm — typically fixed-priority preemptive — to select the highest-priority ready task for execution.
| Algorithm | Description |
|---|---|
| Fixed-priority preemptive | Always runs highest-priority ready task; most common in RTOS |
| Round-robin | Equal-priority tasks share CPU time in rotation |
| Cooperative | Tasks yield voluntarily; no forced preemption |
3 / 41
During a code review your lead says: "This is fine because we use preemptive scheduling — the sensor task will run the moment it becomes ready."
What does preemptive scheduling mean?
What does preemptive scheduling mean?
Correct: B. Preemptive scheduling means the RTOS can interrupt — preempt — the currently running task at any time if a task with higher priority becomes ready (e.g., unblocked by an ISR). This guarantees that the most critical work is always attended to first, which is essential in real-time systems.
| Scheduling type | CPU taken away? | Typical use |
|---|---|---|
| Preemptive | Yes — by higher-priority task | Most RTOSes (FreeRTOS, Zephyr) |
| Cooperative | No — task must yield | Simple or resource-constrained systems |
4 / 41
Your tech lead warns: "We have a classic priority inversion bug in the sensor task — it's waiting on a mutex held by the logging task."
What is priority inversion?
What is priority inversion?
Correct: B. Priority inversion is a scheduling anomaly. It occurs when: (1) a low-priority task holds a mutex, (2) a high-priority task tries to acquire the same mutex and blocks, and (3) medium-priority tasks keep running, starving the high-priority task. The Mars Pathfinder mission famously suffered from this bug.
| Participant | Role in priority inversion |
|---|---|
| High-priority task | Blocked waiting for mutex |
| Low-priority task | Holds mutex but gets preempted |
| Medium-priority tasks | Run freely, preventing low-priority task from finishing |
5 / 41
A colleague says: "We solved the priority inversion by implementing the priority ceiling protocol on that shared mutex."
What does the priority ceiling protocol do?
What does the priority ceiling protocol do?
Correct: B. The priority ceiling protocol (PCP) assigns each shared resource a ceiling equal to the maximum priority of any task that will ever lock it. When a task locks the resource its priority is immediately raised to that ceiling, so no medium-priority task can preempt it before it releases the resource — eliminating priority inversion.
| Protocol | Mechanism | Notes |
|---|---|---|
| Priority ceiling | Raise locker to ceiling on lock | Prevents inversion; POSIX PRIO_PROTECT |
| Priority inheritance | Raise locker when contention detected | Mitigates inversion; POSIX PRIO_INHERIT |
6 / 41
PR Description:
"Fix: Improved latency for data acquisition from the sensor. Updated the TaskA stack size to 2048 bytes and implemented a real-time priority of 5. This should significantly reduce jitter in the sensor readings."This question tests understanding of how stack sizes and priorities interact within an RTOS. While a larger stack *can* provide more space for code execution (though this isn't the primary factor in latency), the key here is that increasing the priority of
TaskA allows the scheduler to preempt other tasks, guaranteeing it gets CPU time when the sensor data needs to be acquired—directly addressing the PR's objective. The misconception lies in assuming a larger stack always equates to faster execution; RTOS scheduling prioritizes based on priority and timing constraints.7 / 41
The term 'context switch priority' is crucial in RTOS scheduling. It doesn't simply mean the frequency of switching; instead, it refers to a task's *relative* importance within the scheduler's decision-making process—a higher priority means the scheduler is more likely to select that task for execution when its time slice arrives. Setting 'High' in this case indicates Task C should be favoured over other tasks with lower priorities, leading to quicker response times. Misunderstanding this leads to inefficient scheduling and potential performance bottlenecks.
8 / 41
Sarah: "Hey team, I'm seeing a lot of complaints about the data logger task taking ages to respond. The API response times from the sensor are consistently high, and it's impacting our overall system performance. I've noticed Task B, which is responsible for processing the raw sensor data, is frequently blocked while waiting for the logger to complete its operation."
What does Sarah likely mean by 'blocked while waiting'? Consider the RTOS concepts involved.Sarah describes a situation where Task B is 'blocked waiting', meaning it's paused its execution while waiting for another task (the logger) to complete. This highlights a common issue in RTOS environments: tasks can become blocked when they are dependent on other tasks and those tasks haven't yet finished their operations. The scheduler, in this case, is likely preventing Task B from continuing until the logger releases the resource it needs, demonstrating a dependency that requires careful management – often through priority levels or synchronization mechanisms.
9 / 41
During a Slack discussion about optimizing the performance of a temperature sensor task, David asks: 'I'm trying to ensure this task gets priority over other tasks that might be accessing shared resources. What mechanism allows me to explicitly influence the RTOS scheduler's decision-making process regarding task priorities?'.
The question targets understanding real-time scheduling, which is fundamental to an RTOS. While options A, B, and D describe related concepts (thread allocation, dynamic priority adjustment, and task priorities respectively), option C – *Real-Time Scheduling* – directly addresses the scenario by defining a scheduling algorithm designed for deterministic execution and meeting deadlines, aligning with David's request to influence the scheduler's decision. Options A and B are incorrect because they describe different approaches or features of an RTOS rather than the core mechanism for prioritizing tasks.
10 / 41
PR Description:
"Fix: Improved latency for data acquisition from the sensor. Updated the TaskA stack size to 2048 bytes and implemented a real-time priority of 5. This should significantly reduce jitter in the sensor readings."This question tests understanding of how stack sizes and priorities interact within an RTOS. While a larger stack *can* provide more space for code execution (though this isn't the primary factor in latency), the key here is that increasing the priority of
TaskA allows the scheduler to preempt other tasks, guaranteeing it gets CPU time when the sensor data needs to be acquired—directly addressing the PR's objective. The misconception lies in assuming a larger stack always equates to faster execution; RTOS scheduling prioritizes based on priority and timing constraints.11 / 41
The term 'context switch priority' is crucial in RTOS scheduling. It doesn't simply mean the frequency of switching; instead, it refers to a task's *relative* importance within the scheduler's decision-making process—a higher priority means the scheduler is more likely to select that task for execution when its time slice arrives. Setting 'High' in this case indicates Task C should be favoured over other tasks with lower priorities, leading to quicker response times. Misunderstanding this leads to inefficient scheduling and potential performance bottlenecks.
12 / 41
Sarah: "Hey team, I'm seeing a lot of complaints about the data logger task taking ages to respond. The API response times from the sensor are consistently high, and it's impacting our overall system performance. I've noticed Task B, which is responsible for processing the raw sensor data, is frequently blocked while waiting for the logger to complete its operation."
What does Sarah likely mean by 'blocked while waiting'? Consider the RTOS concepts involved.Sarah describes a situation where Task B is 'blocked waiting', meaning it's paused its execution while waiting for another task (the logger) to complete. This highlights a common issue in RTOS environments: tasks can become blocked when they are dependent on other tasks and those tasks haven't yet finished their operations. The scheduler, in this case, is likely preventing Task B from continuing until the logger releases the resource it needs, demonstrating a dependency that requires careful management – often through priority levels or synchronization mechanisms.
13 / 41
During a Slack discussion about optimizing the performance of a temperature sensor task, David asks: 'I'm trying to ensure this task gets priority over other tasks that might be accessing shared resources. What mechanism allows me to explicitly influence the RTOS scheduler's decision-making process regarding task priorities?'.
The question targets understanding real-time scheduling, which is fundamental to an RTOS. While options A, B, and D describe related concepts (thread allocation, dynamic priority adjustment, and task priorities respectively), option C – *Real-Time Scheduling* – directly addresses the scenario by defining a scheduling algorithm designed for deterministic execution and meeting deadlines, aligning with David's request to influence the scheduler's decision. Options A and B are incorrect because they describe different approaches or features of an RTOS rather than the core mechanism for prioritizing tasks.
14 / 41
PR Description:
"Fix: Improved latency for data acquisition from the sensor. Updated the TaskA stack size to 2048 bytes and implemented a real-time priority of 5. This should significantly reduce jitter in the sensor readings."This question tests understanding of how stack sizes and priorities interact within an RTOS. While a larger stack *can* provide more space for code execution (though this isn't the primary factor in latency), the key here is that increasing the priority of
TaskA allows the scheduler to preempt other tasks, guaranteeing it gets CPU time when the sensor data needs to be acquired—directly addressing the PR's objective. The misconception lies in assuming a larger stack always equates to faster execution; RTOS scheduling prioritizes based on priority and timing constraints.15 / 41
The term 'context switch priority' is crucial in RTOS scheduling. It doesn't simply mean the frequency of switching; instead, it refers to a task's *relative* importance within the scheduler's decision-making process—a higher priority means the scheduler is more likely to select that task for execution when its time slice arrives. Setting 'High' in this case indicates Task C should be favoured over other tasks with lower priorities, leading to quicker response times. Misunderstanding this leads to inefficient scheduling and potential performance bottlenecks.
16 / 41
Sarah: "Hey team, I'm seeing a lot of complaints about the data logger task taking ages to respond. The API response times from the sensor are consistently high, and it's impacting our overall system performance. I've noticed Task B, which is responsible for processing the raw sensor data, is frequently blocked while waiting for the logger to complete its operation."
What does Sarah likely mean by 'blocked while waiting'? Consider the RTOS concepts involved.Sarah describes a situation where Task B is 'blocked waiting', meaning it's paused its execution while waiting for another task (the logger) to complete. This highlights a common issue in RTOS environments: tasks can become blocked when they are dependent on other tasks and those tasks haven't yet finished their operations. The scheduler, in this case, is likely preventing Task B from continuing until the logger releases the resource it needs, demonstrating a dependency that requires careful management – often through priority levels or synchronization mechanisms.
17 / 41
During a Slack discussion about optimizing the performance of a temperature sensor task, David asks: 'I'm trying to ensure this task gets priority over other tasks that might be accessing shared resources. What mechanism allows me to explicitly influence the RTOS scheduler's decision-making process regarding task priorities?'.
The question targets understanding real-time scheduling, which is fundamental to an RTOS. While options A, B, and D describe related concepts (thread allocation, dynamic priority adjustment, and task priorities respectively), option C – *Real-Time Scheduling* – directly addresses the scenario by defining a scheduling algorithm designed for deterministic execution and meeting deadlines, aligning with David's request to influence the scheduler's decision. Options A and B are incorrect because they describe different approaches or features of an RTOS rather than the core mechanism for prioritizing tasks.
18 / 41
PR Description:
"Fix: Improved latency for data acquisition from the sensor. Updated the TaskA stack size to 2048 bytes and implemented a real-time priority of 5. This should significantly reduce jitter in the sensor readings."This question tests understanding of how stack sizes and priorities interact within an RTOS. While a larger stack *can* provide more space for code execution (though this isn't the primary factor in latency), the key here is that increasing the priority of
TaskA allows the scheduler to preempt other tasks, guaranteeing it gets CPU time when the sensor data needs to be acquired—directly addressing the PR's objective. The misconception lies in assuming a larger stack always equates to faster execution; RTOS scheduling prioritizes based on priority and timing constraints.19 / 41
The term 'context switch priority' is crucial in RTOS scheduling. It doesn't simply mean the frequency of switching; instead, it refers to a task's *relative* importance within the scheduler's decision-making process—a higher priority means the scheduler is more likely to select that task for execution when its time slice arrives. Setting 'High' in this case indicates Task C should be favoured over other tasks with lower priorities, leading to quicker response times. Misunderstanding this leads to inefficient scheduling and potential performance bottlenecks.
20 / 41
Sarah: "Hey team, I'm seeing a lot of complaints about the data logger task taking ages to respond. The API response times from the sensor are consistently high, and it's impacting our overall system performance. I've noticed Task B, which is responsible for processing the raw sensor data, is frequently blocked while waiting for the logger to complete its operation."
What does Sarah likely mean by 'blocked while waiting'? Consider the RTOS concepts involved.Sarah describes a situation where Task B is 'blocked waiting', meaning it's paused its execution while waiting for another task (the logger) to complete. This highlights a common issue in RTOS environments: tasks can become blocked when they are dependent on other tasks and those tasks haven't yet finished their operations. The scheduler, in this case, is likely preventing Task B from continuing until the logger releases the resource it needs, demonstrating a dependency that requires careful management – often through priority levels or synchronization mechanisms.
21 / 41
During a Slack discussion about optimizing the performance of a temperature sensor task, David asks: 'I'm trying to ensure this task gets priority over other tasks that might be accessing shared resources. What mechanism allows me to explicitly influence the RTOS scheduler's decision-making process regarding task priorities?'.
The question targets understanding real-time scheduling, which is fundamental to an RTOS. While options A, B, and D describe related concepts (thread allocation, dynamic priority adjustment, and task priorities respectively), option C – *Real-Time Scheduling* – directly addresses the scenario by defining a scheduling algorithm designed for deterministic execution and meeting deadlines, aligning with David's request to influence the scheduler's decision. Options A and B are incorrect because they describe different approaches or features of an RTOS rather than the core mechanism for prioritizing tasks.
22 / 41
Review Comment:
`@john.doe: 'Just a heads up, increasing the priority of Task D to 'High' might not solve the latency issue if the sensor itself is the bottleneck. Have you considered profiling the sensor API calls to identify potential bottlenecks?'
This scenario presents a code review comment. The core point here is that simply increasing priority doesn't address the root cause – in this case, the sensor API. It correctly highlights that the sensor's response time is likely the limiting factor, and focusing on that would be more effective than just manipulating priorities. Option A misinterprets the comment; options C & D are incorrect as they suggest a simplistic solution.
23 / 41
Slack Message:
`@emma.smith: 'I've been experimenting with setting the Task B's real-time priority to 'Critical'. It seems like it's reduced the time between data readings, but I'm worried about potential starvation for other tasks.'
This question tests understanding of 'starvation' within an RTOS context. 'Critical' priority, while intended to prioritize a task, can lead to a situation where other tasks are indefinitely delayed due to the higher-priority task continually preempting them. Options A & B misrepresent how real-time priorities work; option D is completely unrelated.
24 / 41
PR Description:
"Added a new API call to the sensor module that uses DMA for data transfer. This significantly reduces CPU overhead and improves response times by approximately 20% as measured in our benchmark tests."
This question tests understanding of DMA's role in RTOS performance. DMA enables peripherals (like sensors) to access memory directly, bypassing the CPU and dramatically reducing latency and overhead. The key takeaway is that this is a *hardware-level* optimization, not just a software change.
25 / 41
Standup Update:
"I've been tweaking the Task E's context switch frequency to reduce overhead. I'm aiming for a lower frequency, but I'm concerned about increased latency if the task needs to respond quickly."
This scenario focuses on the trade-offs involved in RTOS configuration. Reducing the context switch frequency *can* reduce overhead but increases latency if rapid response is needed. It's a delicate balance – too low and tasks aren't responsive enough; too high and you waste CPU cycles with unnecessary switching. Option A & B are incorrect assumptions.
26 / 41
API Response:
The RTOS API returned the following message: `{"status": "OK", "task_priority": "Medium", "context_switch_count": 1234}`. A developer is troubleshooting a slow sensor task.
This question tests interpretation of RTOS API responses. The high 'context_switch_count' suggests that the task is frequently being preempted (interrupted) by other tasks, which could be a significant contributor to latency. This is critical information for troubleshooting performance problems. Options A & B misinterpret the meaning of the response values.
27 / 41
Review Comment:
`@john.doe: 'Just a heads up, increasing the priority of Task D to 'High' might not solve the latency issue if the sensor itself is the bottleneck. Have you considered profiling the sensor API calls to identify potential bottlenecks?'
This scenario presents a code review comment. The core point here is that simply increasing priority doesn't address the root cause – in this case, the sensor API. It correctly highlights that the sensor's response time is likely the limiting factor, and focusing on that would be more effective than just manipulating priorities. Option A misinterprets the comment; options C & D are incorrect as they suggest a simplistic solution.
28 / 41
Slack Message:
`@emma.smith: 'I've been experimenting with setting the Task B's real-time priority to 'Critical'. It seems like it's reduced the time between data readings, but I'm worried about potential starvation for other tasks.'
This question tests understanding of 'starvation' within an RTOS context. 'Critical' priority, while intended to prioritize a task, can lead to a situation where other tasks are indefinitely delayed due to the higher-priority task continually preempting them. Options A & B misrepresent how real-time priorities work; option D is completely unrelated.
29 / 41
PR Description:
"Added a new API call to the sensor module that uses DMA for data transfer. This significantly reduces CPU overhead and improves response times by approximately 20% as measured in our benchmark tests."
This question tests understanding of DMA's role in RTOS performance. DMA enables peripherals (like sensors) to access memory directly, bypassing the CPU and dramatically reducing latency and overhead. The key takeaway is that this is a *hardware-level* optimization, not just a software change.
30 / 41
Standup Update:
"I've been tweaking the Task E's context switch frequency to reduce overhead. I'm aiming for a lower frequency, but I'm concerned about increased latency if the task needs to respond quickly."
This scenario focuses on the trade-offs involved in RTOS configuration. Reducing the context switch frequency *can* reduce overhead but increases latency if rapid response is needed. It's a delicate balance – too low and tasks aren't responsive enough; too high and you waste CPU cycles with unnecessary switching. Option A & B are incorrect assumptions.
31 / 41
API Response:
The RTOS API returned the following message: `{"status": "OK", "task_priority": "Medium", "context_switch_count": 1234}`. A developer is troubleshooting a slow sensor task.
This question tests interpretation of RTOS API responses. The high 'context_switch_count' suggests that the task is frequently being preempted (interrupted) by other tasks, which could be a significant contributor to latency. This is critical information for troubleshooting performance problems. Options A & B misinterpret the meaning of the response values.
32 / 41
Review Comment:
`@john.doe: 'Just a heads up, increasing the priority of Task D to 'High' might not solve the latency issue if the sensor itself is the bottleneck. Have you considered profiling the sensor API calls to identify potential bottlenecks?'
This scenario presents a code review comment. The core point here is that simply increasing priority doesn't address the root cause – in this case, the sensor API. It correctly highlights that the sensor's response time is likely the limiting factor, and focusing on that would be more effective than just manipulating priorities. Option A misinterprets the comment; options C & D are incorrect as they suggest a simplistic solution.
33 / 41
Slack Message:
`@emma.smith: 'I've been experimenting with setting the Task B's real-time priority to 'Critical'. It seems like it's reduced the time between data readings, but I'm worried about potential starvation for other tasks.'
This question tests understanding of 'starvation' within an RTOS context. 'Critical' priority, while intended to prioritize a task, can lead to a situation where other tasks are indefinitely delayed due to the higher-priority task continually preempting them. Options A & B misrepresent how real-time priorities work; option D is completely unrelated.
34 / 41
PR Description:
"Added a new API call to the sensor module that uses DMA for data transfer. This significantly reduces CPU overhead and improves response times by approximately 20% as measured in our benchmark tests."
This question tests understanding of DMA's role in RTOS performance. DMA enables peripherals (like sensors) to access memory directly, bypassing the CPU and dramatically reducing latency and overhead. The key takeaway is that this is a *hardware-level* optimization, not just a software change.
35 / 41
Standup Update:
"I've been tweaking the Task E's context switch frequency to reduce overhead. I'm aiming for a lower frequency, but I'm concerned about increased latency if the task needs to respond quickly."
This scenario focuses on the trade-offs involved in RTOS configuration. Reducing the context switch frequency *can* reduce overhead but increases latency if rapid response is needed. It's a delicate balance – too low and tasks aren't responsive enough; too high and you waste CPU cycles with unnecessary switching. Option A & B are incorrect assumptions.
36 / 41
API Response:
The RTOS API returned the following message: `{"status": "OK", "task_priority": "Medium", "context_switch_count": 1234}`. A developer is troubleshooting a slow sensor task.
This question tests interpretation of RTOS API responses. The high 'context_switch_count' suggests that the task is frequently being preempted (interrupted) by other tasks, which could be a significant contributor to latency. This is critical information for troubleshooting performance problems. Options A & B misinterpret the meaning of the response values.
37 / 41
Review Comment:
`@john.doe: 'Just a heads up, increasing the priority of Task D to 'High' might not solve the latency issue if the sensor itself is the bottleneck. Have you considered profiling the sensor API calls to identify potential bottlenecks?'
This scenario presents a code review comment. The core point here is that simply increasing priority doesn't address the root cause – in this case, the sensor API. It correctly highlights that the sensor's response time is likely the limiting factor, and focusing on that would be more effective than just manipulating priorities. Option A misinterprets the comment; options C & D are incorrect as they suggest a simplistic solution.
38 / 41
Slack Message:
`@emma.smith: 'I've been experimenting with setting the Task B's real-time priority to 'Critical'. It seems like it's reduced the time between data readings, but I'm worried about potential starvation for other tasks.'
This question tests understanding of 'starvation' within an RTOS context. 'Critical' priority, while intended to prioritize a task, can lead to a situation where other tasks are indefinitely delayed due to the higher-priority task continually preempting them. Options A & B misrepresent how real-time priorities work; option D is completely unrelated.
39 / 41
PR Description:
"Added a new API call to the sensor module that uses DMA for data transfer. This significantly reduces CPU overhead and improves response times by approximately 20% as measured in our benchmark tests."
This question tests understanding of DMA's role in RTOS performance. DMA enables peripherals (like sensors) to access memory directly, bypassing the CPU and dramatically reducing latency and overhead. The key takeaway is that this is a *hardware-level* optimization, not just a software change.
40 / 41
Standup Update:
"I've been tweaking the Task E's context switch frequency to reduce overhead. I'm aiming for a lower frequency, but I'm concerned about increased latency if the task needs to respond quickly."
This scenario focuses on the trade-offs involved in RTOS configuration. Reducing the context switch frequency *can* reduce overhead but increases latency if rapid response is needed. It's a delicate balance – too low and tasks aren't responsive enough; too high and you waste CPU cycles with unnecessary switching. Option A & B are incorrect assumptions.
41 / 41
API Response:
The RTOS API returned the following message: `{"status": "OK", "task_priority": "Medium", "context_switch_count": 1234}`. A developer is troubleshooting a slow sensor task.
This question tests interpretation of RTOS API responses. The high 'context_switch_count' suggests that the task is frequently being preempted (interrupted) by other tasks, which could be a significant contributor to latency. This is critical information for troubleshooting performance problems. Options A & B misinterpret the meaning of the response values.
Frequently Asked Questions
What does the "RTOS Fundamentals Vocabulary — Embedded & RTOS Language Exercises" exercise cover?
Practice essential English vocabulary for RTOS concepts: task, scheduler, preemptive scheduling, priority inversion, and priority ceiling protocol used in embedded systems engineering.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "RTOS Fundamentals Vocabulary — Embedded & RTOS Language Exercises"?
This exercise has 41 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Embedded & RTOS exercises?
Browse the full Embedded & RTOS hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.