Nova+Nul one Execution Context suspend a second Execution Context

Mehdi AICHOUCH foxmehdi at gmail.com
Wed Dec 12 18:13:23 CET 2012


Hello Alexander,

I  wrote a simple example to test the NOVA+NUL.
In my example, I created two Execution Contexts.

When the the first Execution Context starts, it obtains a portal capability
to
the second Execution Context, and run a while(true) loop as follow :

...
while(1)
{
Logging::printf("#tsc=%llu\n", now);
nova_call(pt);
}
...

The second Execution Context run also a while(true) loop as follow:

...
while(1) {
count++;
Logging::printf("WorkerThread is working... count= %u\n", count);
}
...

The first Execution Context call the second Execution Context. When the
second Execution Context
receive the call in its portal function, it calls the msleep( ) function on
a TimerHelper instance
that it has already created:

unsigned portal_func(Utcb &utcb, Utcb::Frame &input, bool &free_cap,
cap_sel pid)
{
Logging::printf("Thread will sleep... count=%u\n", count);
timer->msleep(1000);
return ENONE;
}

The problem is that, it is the first Execution Context who is blocked and
not the
second Execution Context.

Could anyone please give me an example of how can I achieve the inverse
case, where the first EC continue running
and suspends the second EC.

this is my code to obtain the portal:

cap_sel pseudonym = alloc_cap();
res = ParentProtocol::get_pseudonym(*utcb, "s0/ec2", 0, pseudonym);
cap_sel pt = alloc_cap();
res = ParentProtocol::get_portal(*utcb, pseudonym, pt, true,
"s0/worker_thread");

Thank you in advance.

Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20121212/3a7a205d/attachment.html>


More information about the l4-hackers mailing list