XMK eXtreme Minimal Kernel experiences? - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: XMK eXtreme Minimal Kernel experiences?
Quoted text here. Click to load it

That certainly was quick.

Quoted text here. Click to load it

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??
We've slightly trimmed the long signature. Click to see the full one.
Re: XMK eXtreme Minimal Kernel experiences?

Quoted text here. Click to load it
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.
<unsolicited recommendation>If you are going to pay for a revisions control
system, I highly recommend Perforce (www.perforce.com).  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. </unsolicited recommendation>

Quoted text here. Click to load it
level),
Quoted text here. Click to load it
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.

Quoted text here. Click to load it
the
flag
I have had this request and/or suggestion before.  I will put it on the TODO
list.

Quoted text here. Click to load it
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..... ;-).




Re: XMK eXtreme Minimal Kernel experiences?

Quoted text here. Click to load it


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?

Quoted text here. Click to load it


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.

Quoted text here. Click to load it

I think I've heard of it. ;)

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
We've slightly trimmed the long signature. Click to see the full one.
Re: XMK eXtreme Minimal Kernel experiences?
Quoted text here. Click to load it
The default/simple scheduler is prioritezed.  Here are some snippets from
'scheduling' document
(http://xmk.sourceforge.net/xmk/docs/schedulers.txt)
<snip>
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.
</snip>

<snip>
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.
</snip>
<snip>
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.
</snip>
<snip>
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.
</snip>



Site Timeline