Exam Questions Flashcards
The Underground Tank Monitoring System is a classic example of an embedded system in that it involves input (sensors/buttons), output (display/printer) and real-time constraints. true/false
an underground tank mointoring system would include all of those logically, so yes
- Several models of computation for embedded systems are described in [Lee:2002].
- The ROS software is a prime example of the publish-and-subscribe model. true/false
true, that s exactly what ROS is
- Finite State Machines can be coded in a number of ways in C.
- In the function-based solution, every state is encoded as a separate function.
true, you have a pointer that memories the address of a function and that is how it changes the current state, by changing whatever is in that pointer variable.
Specifying the type of statefp is difficult in C because forward declarations are not supported for function types.
- what are forward declarations?
- a statement that declares the existence of a variable or struct or function without providing any actual implementation for it
- usually when a program needs to refer to a function or struct that has not yet been declared in code, but will be declared later
- and, it is supported in C.
- thus the statement is FALSE
Valgrind is programming tool that provides controlled execution, as well as post mortem inspection of an executable.
this is false because this is actually what GDB does.
To guarantee atomicity task switching must be disabled.
- Atomicity is when a set of instructins to happen as a single, indivisible unit. An atomic op
- guarateed to execute completly and without interruption
- no intermediate states visible to other operations
- they are either fully executed or not at all
- no ops can interffer with them during operations
- usually implemented with mutexes and semaphores
- Interrupts and atomicity
- Because interrupts can interrupt execution, they can be disabled during critical sections to avoid them firing during an atomic op.
- or they can use mutexes etc
Task switching
- it s very important to the CPU and disabling it is usually not an option, or a very bad one
- to preserve atomicity and not have it be affected by ttask switching (witch usually cant even be disabled) the only practical and used way is to use mutexes and semaphores.
- so, disabling task switching is a bad idea, cant be done and the answer is false
- to preserve atomicity and not have it be affected by ttask switching (witch usually cant even be disabled) the only practical and used way is to use mutexes and semaphores.
- Since disabling interrupts increases interrupt latency, several alternative methods have been developed for dealing with shared data.
- The Alternating Buffers technique can be used between two “communicating” tasks provided that the “producer” runs at a higher priority than the “consumer”.
- Alternating Buffer
- it is a technique for dealing with shared data.
- multiple buffers are used to hold shared data.
- each thread uses its own buffer where it writes or reads data, or at least there are many buffers that can do this. This is faster then mutexes or semaphores as it has far less overhead and is better for the shared data. However it is difficult to implement and work with, but it can be done in very memory / power /computation critical systems
- Yes it is based on the consumer and producer design pattern and the producer must have a higher priority for it to make sense.
- it is a technique for dealing with shared data.
Priority inversionrequires a minimum of 3 tasks of different priority and 1 semaphoreto occur.
- this is to be remebered because it s a standard question
- So, for a deadly embrace you need at least 2 tasks to hold eachother resources and mutexes.
- But for priority inversion you need at least 1 semaphore and at least 3 tasks to invert the priority.
- (Think about cups)
An interrupt vector contains the address of an ISR.
The itnerrupt vector is a vector containing the address of ISRs.
An ISR must be reentrant.
this is false because it should be reentrat but if u really need to, u can make it non reentrant. A bullshit question but remember it.
The software architecture of the Network Simulator NS2 mainly uses the data flow computation model.
NS2 (network simulator 2)
- open soruce discrete network network sim that is used for research.
- simulates behaviour of packages transfered through TCP, UDP, HTTP and FTP and others
- The statement is false because NS2 uses the discrete event simulator model.
With an FQS architecture, a task signaled by an ISR is executed immediately after that ISR completes execution.
- well it’s a queue so, if it follows the order of the queue the answer is no. However reasoning about the theory from FQS we know that the tasks have priority among themselves and the ISRs do too. Also, it s logical that ISRs have priority above any task.
- And with all this, also the fact that traditional task switching is not supported in FQS. I think that this would make a lot of sense to be false. Because of the no task switching part. However it is false it implies that after an ISR finishes the signaled task doesnt activate until the queue reaches it.
- function signaled by an ISR means → ISR notifies the scheduler that a certain function is READY to be executed and the ISR schedules the task to be executed as fast as possible (adds it at the killing end of the queue)
- makes it execute as fast as possible
- HOWEVER, this is not as fast as the ISR finishes, because even if it schedules it at the begining of the queue, THER IS A TASK STILL LEFT RUNNING AND THAT MUST FINISH FIRST, so it is not exactly after the ISR finishes.
- IT IS THUS FALSE.
- HOWEVER, this is not as fast as the ISR finishes, because even if it schedules it at the begining of the queue, THER IS A TASK STILL LEFT RUNNING AND THAT MUST FINISH FIRST, so it is not exactly after the ISR finishes.
- makes it execute as fast as possible
- function signaled by an ISR means → ISR notifies the scheduler that a certain function is READY to be executed and the ISR schedules the task to be executed as fast as possible (adds it at the killing end of the queue)
- And with all this, also the fact that traditional task switching is not supported in FQS. I think that this would make a lot of sense to be false. Because of the no task switching part. However it is false it implies that after an ISR finishes the signaled task doesnt activate until the queue reaches it.
A separate hardware timer is needed for providing extremely accurate timing in RTOSs.
- This is false because the hardware timer is built-in for the RTOS systems.
- an RTOS is pretty demanding and thus it has a more powerful chipset installed - >
- it has more stuff on the chipset, like a hardware timer.
- an RTOS is pretty demanding and thus it has a more powerful chipset installed - >
In the RR architecture, the worst-case response time of a task is the sum of the response times of the higher-priority tasks.
false because in RR the tasks have NO PRIORITY.
In an RTOS, tasks can be in state BLOCKED, READY or RUNNING.
- a task starts in the state RUNNING.
- in my logic, blocked is blocked, running is already running and ready is when it is ready to run, so at the instant of the start, it goes from ready → running. I say ready is the answer, thus it is false.
An ISR may change a task’s status from RUNNING to READY.
an ISR can block a task, but to make it ready (considering that the task is interrupted by it) makes no sense. I think it has to go to blocked and then unblock when the ISR is finished executing. → it is false.
An ISR must not invoke an RTOS function that may block.
Interrupting a function and the interrupt itself calling a functionn that may block can cause a clusterfuck as it blocks a running task stopped by an IR. It s a serious clusterfuck of a system event so it must NOT happen as there is no good outcome possible form it. BEst case is the entire system halting or slowing the fuck out of it.
MUST not happen → TRUE
A function can be made reentrant by temporarily disabling interrupts, but additional bookkeeping is required as simply enabling interrupts on exit may cause errors.
This is true.
When upgrading to an RTOS, signaling between ISRs and tasks may still be done through flags residing in global memory.
- Handling of the ISR in an rtos functions in the following way
- there is a “global” counting semaphore on the main shared memory, created with kernel functions. That is used to signal, block, reenter etc of a task / function when a IR is triggered. A flag is a binary thing, however that is not enough, a proper counting semaphore is required for this to work properly
- thus i consider it false, because it should be done with a ‘global’ SEMAPHORE not FLAG.
- there is a “global” counting semaphore on the main shared memory, created with kernel functions. That is used to signal, block, reenter etc of a task / function when a IR is triggered. A flag is a binary thing, however that is not enough, a proper counting semaphore is required for this to work properly
A program running on an RTOS may create tasks dynamically at runtime. the program ends as soon as the main() function returns.
This is false. Think about it like an OS, the os doesnt terminate whenever a function terminate, only when the PC is shutdown. THis is still an OS, but a very low level & specialized one.
the semaphore “lock” must be initalized to 0 in the following C code:
os_pend(lock)
if (++cnt == 1) // first reader
os_pend(read_or_write)
os_post(lock)
…. // read action
os_pend (lock)
if (–cnt == 0) //last reader
os_post(read_or_write)
os_post(lock);
Here, the answer is false.
This is because due to many, many readers, it must be a counting semaphore. A counting semaphore is initalizes with the number of max resources that can simultaniosly aquire a resource, thus if it is 0, a resource can never be aquired and the program will forever halt ->fucked. Must never happen.
reader code : “os_pend(lock)
if (++cnt == 1) // first reader
os_pend(read_or_write)
os_post(lock)
…. // read action
os_pend (lock)
if (–cnt == 0) //last reader
os_post(read_or_write)
os_post(lock);” and writer code : “os_pend(read_or_write)
…// write action
os_post(read_or_write)
QUESTION: Semaphore read_or_write must be initialized to the number of writers.
- the number of tasks that can aquire the resource at one point is the initalization of the semaphore. Now, let s reason about what should that be.
- from what it seems, it is a binary semaphore, and there is only one writer here
- This is false. I got it wrong. Let s see why
- let s anaylize how this code works
- the purpose of ******read_or_write****** is to protect a shared resource that can be accessed by either a single writer or multiple readers at a time.
- this is inialized with a value of 1, which means that one thread can hold it a time. → it s binary
- the purpose of lock is to protect the cnt value.
- also with value of 1, both being binary
- **********the question is thus false, as it must be initalized to 1, as it is binary**********
- also with value of 1, both being binary
- the purpose of ******read_or_write****** is to protect a shared resource that can be accessed by either a single writer or multiple readers at a time.
- let s anaylize how this code works
- This is false. I got it wrong. Let s see why
The writer task can be “locked out” when multiple readers keep doing their actions while cnt never returns to zero.
- Such starvation can be avoided by assigning the writer task a priority higher than any reader.
false, because it remains locked nevertheless by the mutex / semaphore, so priority wouldnt mean anything in this context
The heartbeat timer is a single hardware timer an RTOS is using to verify that the system is still progressing (i.e. not deadlocked).
false. It checks if it is still running and components are still alive. Doesnt check for deadlock as when it is deadlocked, technically it is still running.
An RTOS usually provides two types of delay functions: polling-based and timer-based.
- Polling-based delays
- continiosuly checking (polling) a condition to check when a specific time interval has passed
- Timer-based delays
- this type involve hardware timers trigger an interrupt after a specific time has elapsed.
- There are no ticks specified, thus no.
- Assume that one system clock tick = 10 ms.
- Calling the functionOSTimeDly(4) causes a delay of exactly 40 ms.
false, it is never perfect
- To address the shared-data problem, many RTOSs provide communication primitives likequeues, mailboxes, and pipes.
- the unique property of a mailbox is that it can accept items from different tasks.
- the unique property of a mailbox is that it can accept items from different tasks.
- false.
- MAILBOXES
- sending and receiving messagess between tasks in RTOS.
- fixed sized buffer that can hold multiple messages.
- tasks can send messages to a mailbox and receive using the receive operation
- useful for sending large data structures between tasks
- each data can have VARIABLE LENGTH
- can receive data from multiple tasks.
- the question is false because this isnt what makes it UNIQUE.
- Queues
- a mechanism for sending and receiving data between tasks in an RTOS
- fixed sized buffer that can send data, each has a FIXED LENGTH.
- Pipes
- unidirectional mechanism for sending data between tasks in an RTOS
- a pipe typically has a fixed size buffer that can hold multiple data items, each of witch has a fixed length.
- MAILBOXES
- false.
→ (back to the question) the mailbox has the unique attribute of being able to store data of variable length, and that it can acccept data from multiple tasks is true but NOT UNIQUE, all of them can.
A disadvantage of queues over pipes is that messages/items are handled strictly in FIFO order.
This is false. While a Queue is fifo, this is not striclty as u can have multiple oprations on it + a queue is bidrectioonal while a pipe is unidrectional. THere are many ways to approach this question and they all lead to a false answer. Plus they are not stricly FIFO.