XMK eXtreme Minimal Kernel experiences?

That certainly was quick.

I've been looking through the source code, and I must say it looks quite well-written. My comments so far...

1) Allowing multiple tasks to have the same priority complicates the scheduler implementation. Since there is no mechanism that guarantees "fairness" in the situation where there are multiple tasks at a given priority (such as time-slicing or round-robin within a priority level), I don't think much is bought by the cost incurred. 2) There are no timeouts on wait operations. The projects I've done in the past have all had situations where waiting on a semaphore or event flag with a timeout was extremely handy. Any thread doing communications with the outside world is likely going to have requirements like:

send message

wait up to X ms for reply

if reply received then do this else do that

Being able to place timeouts on semaphonre/event-flag waits allows requirements like that above to map directly into source code without having to create two threads to handle the if/then/else condition.

If you do have to create separate threads (one to wait for an event, and one to wait for a timeout), then you have to use more mutexes/semaphores to coordinate the actions of the two threads, and you have to have mechanisms for one thread to abort the wait operation of another thread. It gets messy and hard to maintain.

Since you've already got a per-task countdown timer, adding an optional timeout on wait operations shouldn't be difficult. 3) If I were using it, I'd probably change the build process so that the kernel is built separately as a library, and then linked with application code.

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
 Click to see the full signature
Reply to
Grant Edwards
Loading thread data ...

Creating the compact-release was easier than I thought it would be. It was more of a case of knowing the feature set of my revision control system, then actual work. The only new files I created where 3 makefiles and the README file for the release, the rest was the magic of Perforce. If you are going to pay for a revisions control system, I highly recommend Perforce

formatting link
It is a whole lot cheaper, simpler to use, provides 'change-sets' capability, works over standard TCP/IP sockets (so working remotely or via VPN is a breeze), then a certain product from Rational Software.

level),

I agree. If I have fewer than 8 threads I almost always use the default (simpler) scheduler because of the difference in the footprints. The user/application gets to choose which scheduler best fits the requirements. Also, the second scheduler was created as a stepping stone to adding time-slicing scheduling in the future.

the

flag

I have had this request and/or suggestion before. I will put it on the TODO list.

Yes. I fully expect that anyone using XMK will apply their own build environment to it. For the compact-release, the makefiles are just for demonstration purposes only, not a 'production' build environment. But if you want to talk about a production build environments, I happen to know about this great..... ;-).

Reply to
John Taylor

After my first reading, I thought the simpler scheduler wasn't prioritized but after looking through some of the source files again, I guess maybe it is. Right?

Last time I wrote one of these, I made timers a separate type of kernel object that they could start/stop, and threads could wait on a combination of a semaphore+timer. Looking back, I think that was overly complex. I rather prefer having a dedicated "sleep" timer in the TCB that is used to both sleeping and for timouts when waiting for objects like semaphores.

I think I've heard of it. ;)

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
 Click to see the full signature
Reply to
Grant Edwards

The default/simple scheduler is prioritezed. Here are some snippets from 'scheduling' document

formatting link

When using the default scheduler, a thread's priority is also the thread's handle and can be used interchangeably. This consolidation of the thread handle and thread priority has the following effects/features:

o No two threads can have the same priority. o Adding new threads to your application requires adjustments to the application's existing priority scheme. o Managing stack memory for dynamic threads is greatly simplified.

Default Scheduler: o No "self" context switches. The kernel will NEVER perform a context switch such that the 'current' and 'next' thread are the SAME. o Fast context switches on wake-up. When a higher priority thread (than the currently running thread) is signaled/woken-up, the context switch occurs immediately. The context switch time is completely independent of the number of threads. o Not an O(1) scheduler. When a thread voluntary yields the CPU (i.e. makes a blocking call) the amount of time required to find the next ready-to-run thread is dependent on the number of application threads. o Interrupts latencies increase as the number of threads increase.

XMK supplies an alternate scheduler that decouples a thread's handle from the thread's priority (config option: USE_XMK_SCHPRI_SCHEDULER). This alternate scheduler, know as the 'Priority Scheduler', is more flexible, but costs more in terms of RAM and ROM. The Priority Scheduler has the following features:

o Mulitple threads can have the same priority. o The application is required to define (at compile time) the total number of different/unique priorities that can be used by the application. o No guaranty of execution order when there are N ready-to-run threads of the same priority.

Priority Scheduler: o No "self" context switches. The kernel will NEVER perform a context switch such that the 'current' and 'next' thread are the SAME. o Fast context switches on wake-up. When a higher priority thread (than the currently running thread) is signaled/woken-up, the context switch occurs immediately. The context switch time is completely independent of the number of threads. o IS an O(1) scheduler. When a thread voluntary yields the CPU (i.e. makes a blocking call) the amount of time required to find the next ready-to-run is dependent ONLY on the number of priority levels. Since the number of priority levels is fixed (at compile time) and is independent of the total number of threads, the scheduling time does NOT change as the number of threads increases or decresses. o Interrupts latencies do NOT increase as the number of threads increase.

Reply to
John Taylor

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.