Q: What is a RealTime System ?
A: A Real-time system is defined as a system where the response time for an event is predictable and deterministic with minimal latency.
Q: How is RTOS different from a general operating system?
A:
TaskScheduling:
RTOS generally have priority-based preemptive scheduling, which allows high-priority threads to meet their deadlines consistently. Whereas In a GPOS, the scheduler typically uses a "fairness" policy to dispatch threads and processes onto the CPU. Such a policy enables the high overall throughput required by desktop and server applications, but offers no assurances that high-priority, time-critical threads will execute in preference to lower-priority threads.
Preemetive Kernel:
In RTOS, kernel operations are preemptible. And so the RTOS kernel must be simple and elegant as possible.
Mechanisms to Avoid Priority Inversion:
This occurs when a lower-priority thread can inadvertently prevent a higher-priority thread from accessing the CPU. VxWorks specifically has protection for this.
Q: What is a task in VxWorks?
A: A task is an independent program with its own thread of execution and execution context. VxWorks uses a single common address space for all tasks thus avoiding virtual-to-physical memory mapping. Every task contains a structure called the task control block that is responsible for managing the task's context.
Q: How do task's manage the context of execution ?
A: Every task contains a structure called the task control block that is responsible for managing the task's context. A task's context includes
· program counter or thread of execution
· CPU registers
· Stack of dynamic variables and function calls
· Signal handlers
· IO assignments
· Kernel control structures etc.,
Q: What are the Different states of tasks?
A task has 4 states. Read, Pend, Delay, Suspended
Q: Explain the task State transition ?
A: A task can be created with taskInit() and then activated with taskActivate() routine or both these actions can be performed in a single step using taskSpawn(). Once a task is created it is set to the suspend state and suspended until it is activated, after which it is added to the ready queue to be picked up by the scheduler and run. A task may be suspended by either the debugging your task, or the occurrence an exception. The difference between the pend and suspend states is that a task pends when it is waiting for a resource. A task that is put to sleep is added to delay queue.
Q: What is the default scheduling algorithm in vxWorks?
A: By default, vxworks scheduler runs preemtive priority based algorithms. You can change it to rounds robin/timeslicing algorithm.
Q: What are the different types of semaphores in vxworks? Which is the fastest?
A: VxWorks supports three types of semaphores. Binary, mutual exclusion, and counting semaphores. Binary is the fastest semaphore.
Q: When will you use binary semaphore ?
A: Binary semaphores are used for basic task synchronization and communication.
Q: When will you use mutual exclusion semaphore?
A: Mutual exclusion semaphores are sophisticated binary semaphores that are used to address the issues relating to task priority inversion and semaphore deletion in a multitasking environment.
Q: When will you use Counting semaphore?
A: Counting semaphores maintain a count of the number of times a resource is given. This is useful when an action is required for each event occurrence. For example if you have ten buffers, and multiple tasks can grab and release the buffers, then you want to limit the access to this buffer pool using a counting semaphore.
Q: How do you do inter task communication in vxworks?
A: Using message Queues.A variable number of messages, each of variable length, can be sent to any task.
Q: What the special requirements for message Q's and Semaphore handling inside ISR's ?
A: ISR can only send Messages and can only release a semaphore
Q: Can Message be scheduled on priority ?
A: Yes. Multiple tasks can wait on a single message queue and can be ordered by their priority. Messages can be marked urgent for faster delivery.
Q: How is ISR handled in vxworks ?
A: VxWorks supplies interrupt routines which connect to C functions and pass arguments to the functions to be executed at interrupt level. To return from an interrupt, the connected function simply returns. A routine connected to an interrupt in this way is referred to as an interrupt service routine (ISR) or interrupt handler. When an interrupt occurs, the registers are saved, a stack for the arguments to be passed is set up, then the C function is called. On return from the ISR, stack and registers are restored.
Q: How do you connect the C Function to any interrupt?
A: Using intConnect(INUM_TO_IVEC(intNum), intHandler, argToHandler).
The first argument to this routine is the byte offset of the interrupt vector to connect to. The second argument is the interrupt handler and the last is any argument to this handler.
Q: What are the important things to be taken care within ISR?
A:
Avoid blocking calls
No wait for semaphore
No receive messages
No malloc() or free() (since they internally wait fro semaphore)
Q: How can ISR's communicate with user tasks?
A: using:
shared memory and ring buffers
release of semaphores
signaling tasks
writing to pipes
sending messages using message queue
Q:What interfaces are generally exposed from the drivers to application?
A: creat(), remove(), open(), close(), read(), write(), ioctl() are the seven standard driver interfaces that are exposed to application.
Q: Which routine you call to install the driver ?
A: iosDrvInstall()
Q:What is context switching?
A: When the scheduler preempts a task it has to store the current state of the task in task's context storage area and will retrieve it later when the task is resumed. The current runnable tasks context is retrieved. This process of switching the contexts is called task switching or context switching.
Q: Is it possible for an ISR to preempt another ISR?
A: It is possible for an ISR to preempt another ISR, however this is board dependent and may not be allowed. The handling of the hardware interrupt, that in turn invokes the ISR registered for the interrupt, is board specific and is performed by the board support package software (BSP). VxWorks provides an API that allows the developer to register an ISR with the BSP's board specific handler. This abstraction layer allows for board specific code to be segregated from the remainder of the application thus allowing for easier porting to new board types.
Q: How can you stop your code from scheduler preemption?
A: You can tell the system not to preempt your code by using taskLock() and release it later once you finished your critical section code using taskUnlock().
Note this is not a suggested mechanism, as the code cannot be interrupted. Also this might lead to unacceptable real time behavior, because a higher priority task can preempt a lower priority task that locked itself.
Q: What is re-entrency and how you achieve it?
A: If a piece of code can be used by more then one task without the fear of data corruption, then it is said to be Reentrant. A reentrant function can be interrupted at any time and resumed latter without loss or corruption of data.
To achieve reentrancy, use either local variables (i.e variables on stack rather then on heap, and CPU registers etc.,) or treat the code as critical section and protect the data.
Q:How you guarantee cache coherency?
A: This is typically done in two ways.
1) Mark a portion of memory within your RAM as non-cachable. Allocate cache safe buffers from this memory.
2) Alternatively, use cacheFlush() and cacheInvalidate() routines provided by VxWorks. If Device is reading data from RAM, first flush the cache and then read data. If Device is writing to RAM, write to RAM and then invalidate the cache immediately. This way CPU's cache will be in sync with RAM.