Re: [MiNT] kernel 1.15.10b fragmentation

[Johan Klockars <rand@cd.chalmers.se>]

> > > What limitations sets the MiNT kernel?
> > 
> > It has been a long time since I looked into this now (I did some relatively
> > significant work on XaAES two years or so ago), but mainly I was frustrated
> > by the slow and/or limited interprocess communication and synchronization
> > mechanisms.
> > Neither pipes, messages (don't recall what those were actually called),
> > nor even semaphores were near quick (or flexible, in cases) enough to
> > satisfy me.
> 
> Do you have ideas for fast and flexible enough IPC mechanism that match
> your requirements?

The Fenix message passing Sven mentioned would certainly be helpful,
but I'm fond of _really_ light weight mechanisms. In my own real time
kernel (MyRTOS, used in a university course I used to teach), waiting
on a semaphore which isn't taken is just as can be seen below (signaling
takes one or two more instructions). Naturally, if the process must be
suspended (or some other awakened in case of signaling (this is a realtime
kernel, so if a higher priority process is awakened that will resume
immediately)) the context switch time will swamp the semaphore handling,
but there is nothing to do about that case (well, at least not in the
sempahore code).
This uses a resident function library rather than a normal OS call (for
easier interfacing with the C compiler we used), so a special Trap is
used to enter supervisor mode. Supervisor mode does not protect against
preemtion, so interrupts are disabled to ensure mutual exclusion.

_wait_sem:
        move.l  (4,a7),a1
        trap    #0
        or      #$0700,sr
        move.w  d0,crit_sr
        tst.w   (count,a1)
        bne     .ok
	...
.ok:
        subq.w  #1,(count,a1)
        move    crit_sr,sr
        moveq   #1,d0
        rts

It doesn't get much quicker than that, but this was for CPU boards
that didn't support memory protection. Things would certainly get more
complicated in MiNT.

Anyway, no matter how they are implemented, I really do like counted
semaphores that are not owned by a specific process when taken. The MiNT
semaphores can really only be used for mutual exclusion, while mine work
as well for message passing in various forms, etc.

For example, a server that has a buffer for eight messages could be
implemented something like:

  in = 0;
  out = 0;
  init_sem(buf_space, 8);
  init_sem(buf_elements, 0);
  init_sem(mutex, 1);
  loop 
    wait_sem(buf_elements);
    <do something with element 'out'>
    out = (out + 1) % 8;
    signal_sem(buf_space);

Any number of clients could then:

  wait_sem(buf_space);
  wait_sem(mutex);
  my_in = in;
  in = (in + 1) % 8;
  signal_sem(mutex);
  <write message in buffer at position 'my_in'>
  signal_sem(buf_elements);

By adding mutual exclusion for 'out', there could be extra servers too.


This was just something I made up right this minute to give an example
of what you can't do with the MiNT semaphores.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johank@omicron.se
                        | so hard to do |  WWW:      rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (fVDI, MGIFv5, QLem)