(see Altera web pages).
http://www.altera.com/products/ip/processors/nios2/tools/embed-partners/windriver/emb-windriver.html
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This me
Sorry, I don't see the difference except for some minor details
in how the thread is "called" by the scheduler.
With a real thread scheduler Threads can run in a loop and never exit.
Other threads run at appropriate point in time (e.g. when a running
thread request some kind of "wait"). Wai
"Run to completion" means that each "thread" is a callback that is
called and returns with any "event" it needs to handle.
Sorry, bad wording: it should be:
"Run to completion" means that each "thread" is a simple function that
is called and returns with any "event" it needs to handle.
-Mic
What _I_ meant was that when one of my threads gets scheduled,
it runs until it has finished what it needs to do and blocks
waiting for the next event. Isn't that's what "run to
completion" means?
No. "Run to completion" means that each "thread" is a callback that is
called and returns with
Do you know how this is implemented in the x86 architecture ? I
suppose The CPU does not have enough registers to dedicate one for
that purpose, unless something exotic like the Extra Segment is used.
I did a disassembly and I see that in fact it does use the gs segment
register for this purpo
So - even with "full" Linux, the __thread variables have different
addresses per thread ?
Yes.
I did a test on the PC and (as expected) you are right. The same
__thread variable has different addresses when different threads are
running.
Do you know how this is implemented in the x
That's fine if the code is simple enough to be event driven and always
returns to your event scheduler.
Sorry but I can't follow you. You just said in the mail I replied to:
" I know. That's how my threaded app works."
-Michael
___
uClinux-de
Michael Schnell wrote:
> So I don't understand why you bother about "real" threads at
> all. some 50 Lines of C code will "schedule" your "threads" one
> after the other as part of a single application/process, all running
> on the same stack,
That's fine if the code is simple enough to be event d
Michael Schnell wrote:
>
> >No, it's not done like that. Linux does not provide thread-specific
> >virtual memory mappings, except for special cases like the
> >vsyscall/vdso page.
> >
> So - even with "full" Linux, the __thread variables have different
> addresses per thread ?
Yes.
> This d
Of course, the compiler would have to be convinced to leave
that register alone, similar to how it already behaves with the stack pointer
and frame pointer registers.
... and to _use_ it as a pointer for the variables defined with the
"__thread" keyword.
-Michael
_
It should be easy enough to get it to work with a dedicated register, too.
... Provided that it's easy to modify the compiler, which I supposedly
never will be able to do ;-) .
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://ma
No, it's not done like that. Linux does not provide thread-specific
virtual memory mappings, except for special cases like the
vsyscall/vdso page.
So - even with "full" Linux, the __thread variables have different
addresses per thread ? This does not make sense to me as there is an MMU
tha
It only can run after that thread completes (and then waits to
get rescheduled at a later time.
I know. That's how my threaded app works.
So I don't understand why you bother about "real" threads at all. some
50 Lines of C code will "schedule" your "threads" one after the other as
p
Gavin Lambert wrote:
> It should be easy enough to get it to work with a dedicated
> register, too. Just have the kernel set the register on context
> switch, where it always points to a "thread-specific-data" table in
> memory at different locations for different threads. (This would
> also work
Quoth Jamie Lokier:
> Some arches have a page which is per-thread, called the vsyscall/vdso
> kernel page. User-space calls routines in that page. In that page, a
> pointer to the TLS area might be stored, swapped on context switch by
> the kernel, and retrieved by calling a routine at a fixed ad
Michael Schnell wrote:
> >It's not true at all that they use a "default" MMU-enabled TLS scheme
> >- you need arch-specific kernel support for a context switched memory
> >block whether it's with an MMU, or non-SMP without an MMU.
> >
> I did not look into any code for this. I was told that it sh
It's not true at all that they use a "default" MMU-enabled TLS scheme
- you need arch-specific kernel support for a context switched memory
block whether it's with an MMU, or non-SMP without an MMU.
I did not look into any code for this. I was told that it should be easy
and not (largely) ar
Run-to-completion You've lost me. AFAICT, that's pretty much how both
Linux and
all the RTOSes I've ever seen work.
Not at all.
Linux and many "big" RTOSes do "preemptive multitasking": A threat
thread/process gets interrupted and stalled for some time, if a higher
priority get act
I'll try to be clear: I've got a threaded application. It
works fine with eCos. I want to run the same code on Linux
without adding a lot of latency.
That supposedly is not possible. I suppose, eCos is a RealTime OS, Linux
is not. That is why Linux offers a lot "standard" features, while eC
Michael Schnell wrote:
> Of course I do know, but NPTL is based on TLS and TLS is much easier
> to to if you have an MMU that can provide the dedicated per-thread
> memory block automatically the the system switches the MMU
> configuration on a process/task switch. The MMU based implementation
> se
Jamie Lokier wrote:
Michael Schnell wrote:
TLS, NTPL, FUTEX, not signal based IPC, ...) Hopefully the upcoming
MMU-enabled NIOS uClinux will take care of most of this - as most is
a lot easier to do based on TLS and same is easy to do if making use
of the MMU..
That stuff doesn't depen
Michael Schnell wrote:
> TLS, NTPL, FUTEX, not signal based IPC, ...) Hopefully the upcoming
> MMU-enabled NIOS uClinux will take care of most of this - as most is
> a lot easier to do based on TLS and same is easy to do if making use
> of the MMU..
That stuff doesn't depend on an MMU, really.
It
There in fact _is_ a pure userspace implementation of threads.
I suppose the project is really old and not active any more.
-Michael
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This mes
I'm surprised nobody has mentioned the real-time Linux patches :-)
Specifically the PREEMPT_RT tree.
"Preemptible Kernel" is enabled with the NIOS uCLinux by default. Of
course this does reduce problems with priority inversion.
I don't suppose additional low latency patches are available f
Could be. I'm not sure which posix implementation is used on
the NIOS. Some implementations did do everything in
user-space, and I thought I read that the NIOS port used one of
those.
We did discuss this some time ago. There in fact _is_ a pure userspace
implementation of threads. But with
I feel that replying to a message on a TCP connection is not
doable as a really hard realtime task.
That depends on what the specs are.
Of course you are right here. "Guaranteed reaction within 24 hours" does
qualify as hard real time :).
Real time doesn't imply zero-copy. _Fas
Grant Edwards wrote:
> > or do the hard realtime stuff in hardware (if same can be
> > reduced to very simple functions).
>
> That last qualification is an important one. When I've asked
> in the NIOS forums about RTAI or other ways to control latency
> on the NIOS/Linux platform, the answer is a
it doesn't even
have NPTL support. That means that scheduling of threads is
being done by user-space code.
I suppose that you are wrong with that conclusion. If the thread
scheduling in fact would be done completely in user-space it would be
_really_ fast, as the OS would not be involved. B
Um, isn't that what RTAI does -- run the linux kernel on a
virtualized processor?
Yep, but AFAIK, in the "realtime" part, you need to use what RTAI
offers. You can't install some RTOS there.
As one of my friends used to say: "the only
thing worse than a product based on a microprocessor is
29 matches
Mail list logo
