DelegateSystem for ISRs and scheduling

[skeen]

Hi all!

I've just got finished designing my delegate system, that I've been planning on using for ISRs and scheduling.
As I'm writing my kernel in C++11, I've decided to go for a full blown implementation using variadic templates, and I'm actually quite pleased with the result, one can use it alike this;

Code: Select all

// ct = Creation Time, rt = Run Time
void function(Tuple<char,int> ct_args,  Tuple<const char*> rt_args)
{
    printf("%c%d%s", get<0>(ct_args), get<1>(ct_args), get<0>(rt_args));
}

Runnable<const char*>* callable1 = makeRunnable(function, 'C', -3);
callable1->invoke("PO");

Which will result in the text; "C-3PO" being printed (obviously this works with any number of arguments, and any types, no type information is lost in the progress, and no casts are being performed).

And if for some reason one doesn't like the tuples, one can get rid of them using a little wrapper, using a simple tuple_concat and the unwind the tuple, this involves a wrapper of course.

Now to the question;

I'm currently using it in my scheduling (in my createThread(Runnable*) function), and I was going to use it in my ISR system too (to handle interrupts), however it has now come to my mind that maybe I should use my delegate system less, due to it's memory usage, and the overhead of the virtual function call.

The function delegate uses memory as stated below;

• * 0-1 u32int (or 0-4 u8int) arguments = 12 bytes
  * 2 u32int (or 5-8 u8int) arguments = 16 bytes

Intervals (since it's not a packed structure obviously, and since the compiler sets 4bytes apart for the tuple (empty or not)), the object delegates is 4 bytes larger (due to the object reference). Do note however that it's only the ct_args that add to the size of the object, as the rt_args are passed directly.

So will the overhead in memory and speed end up giving me trouble, or can I just go use my system wherever I feel like it, without concern?

//Skeen

[mrvn]

Theoretical answere: A context switch on x86 (by the hardware) takes well over 1000 cycles alone. Accessing 16 bytes of memory is totaly negible compared to that.

Practical answere: You will know it when you try it.

MfG
Mrvn

[skeen]

Theoretical answere: A context switch on x86 (by the hardware) takes well over 1000 cycles alone. Accessing 16 bytes of memory is totaly negible compared to that.

Practical answere: You will know it when you try it.

MfG
Mrvn

Does it really take over 1000 cycles? - I knew the fact, that it was expensive, but didn't know that, it was that expensive. wow!
Alright, but that's kinda good, then I'll go ahead and use my delegate system for that as well

[bluemoon]

It may be true for hardware task switch (task gates), but for software task switch, or stack switch by going to/from ring0, it is pretty quick for modern cpu.

[gerryg400]

I tested syscall, int and hw interrupt latency on my PC. I don't have the results at hand but they we of the order of 100 cycles max. I will post the results if I can dig them up.

[skeen]

I guess I'll just try it out, and see if I get the issues then