| |
I guess my earlier posting got out after all. I got the message from
the NNTP server telling me to register. That is why a slightly
different version of my message appears later in the group.
"Markus L. Noga" wrote:
>
> Lou Sortman wrote:
> > I think I can achieve a similar effect by putting the idle task at the
> > lowest priority in my structure. The caveat would be that one should
>
> The idle task actually has the lowest priority in my scheme, but there
> was some efficiency gained in making the task list loop around. If the
> idle task is always there, it makes for simplified code in multitasking
> startup if you rely on that.
I plan to keep the idle task, now that I understand it better. It seems
better to do it that way than to wrestle with putting the micro into
sleep mode while in an ISR.
>
> Of cause, changing the structure into a linked list of priority levels,
> each of which is a linked list of tasks within a level might change
> that. Within a priviledge level, you might want to make the lists
> circular, too - saves reordering.
That is what I am doing, and for that reason. Instead of reordering the
processes, I simply change a pointer in the priority structure.
> > insert a sleep task in the middle of the
> > chain to temporarily disable lower priority tasks.
>
> Task management is still missing suspend and resume functionality on a
> task-specific level. I'm uncertain whether to favour the unix signal
> mechanism or not, though. Do we need that many signals? 16 signals imply
> 32 bytes of handler vector table.
Do you know of 16 signals appropriate to this context? I can think of
about 8, which is still 16 bytes per process.
QUIT INT STOP START HUP ALRM USR1 USR2
I'm not sure if there'd be much difference between QUIT and INT.
You could separately allocate the signal vector table, and do so only if
custom signal actions are registered which differ from the default (call
to signal()). When sending a signal, if that pointer is blank, go to a
systemwide default table with things like QUIT and ALRM, which apply the
same way to any process, in it. There would, of course, be more
execution overhead, but only when registering a signal or sending one.
The idea is that most processes would probably use the default table,
thus using only 2 bytes rather than 34 (or 18).
What other signal models do you know of?
I have been entertaining thoughts of a message passing scheme, where
processes can wait on a message queue for messages. The same scheme
could have a special block of messages (bit7 of the message-type set,
for example) which are caught by the kernel and interrupt waits (as a
signal would), possibly dispatching one big signal handler with a switch
in it. It would get rid of the fixed-size vector table, but would
require more work on the part of the programmer to handle things like
QUIT, etc. Even if this is not a good way to do signals, I think
message passing would be good to have anyway. Either directly to a pid
or something like Unix domain datagram sockets. Actually, the latter
fixes the problem of knowing which pid to send to. I am busy with the
scheduler right now.
>
> > As you might have surmised by now, I am a sucker for elegance,
> > efficiency, and flexibility.
>
> Heh... try and figure out how to keep gcc from saving r4...r6 when
> entering and leaving tm_scheduler(). It's totally superfluous. You can't
> change it in tm_switcher, otherwise you'd end up with r0..r3 from the
> new task context and r4..r6 from the old one.
Man, I haven't even poked down at that level. You have obviously dealt
with quite a bit of ugliness with regard to getting gcc to play nice.
|
|
Message has 1 Reply:
 | | Re: Idle process
|
| Hi Lou, I'm discussing datagram networking with Jacob Barrett currently. They have some people working on it. The idea is to provide 1 byte of address space, using a per-host hostmask, just like TCP/IP uses per-net netmasks. A host with address 0x10 (...) (26 years ago, 19-Mar-99, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: Idle process
|
| (...) The idle task actually has the lowest priority in my scheme, but there was some efficiency gained in making the task list loop around. If the idle task is always there, it makes for simplified code in multitasking startup if you rely on that. (...) (26 years ago, 11-Mar-99, to lugnet.robotics.rcx.legos)
|
10 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
