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