Subj : Re: JOB: Sandbridge Technologies, White Plains, NY
To   : comp.programming.threads
From : Joe Seigh
Date : Fri Jul 15 2005 10:31 am

Mayan Moudgill wrote:
> 
> I apologize in advance if job postings are off-topic/deprecated in this 
> group.
> 
> To summarize: we're looking for someone who can grow/replace a pthread 
> based RTOS for our multi-threaded chip. You can read about our company 
> at www.sandbridgetech.com. Send me e-mail if you're interested. Its a 
> pretty challenging job, working with a small team of fairly competent 
> systems programmers.
> 
> A little more detail: we have built a 4 core chip, where each core has 8 
> *hardware threads* targetted for cell-phone base-band processing.
> 
> Briefly each core:
> - is low power
> - has 8 hardware threads
> - issuing 3 way LIW intructions
> - with a 4-way SIMD (vector) unit
> - running at 600MHz+
> 
> We've also got a pretty nice set of tools for it, including a 
> vectorizing/multi-threading compiler and a fast simulator.
> 
> You can find more details 
> http://www.sandbridgetech.com/documents/sandbridge_white_paper_2005.pdf

Not yet, your website isn't accessible.
> 
> Currently we've got an RTOS built around the POSIX thread standard. Its 
> quite serviceable, *but* we'd like to grow it. We're looking for someone 
> who can figure out what to replace, what to optimize and how to extend 
> the POSIX standard to support real hardware threads, and then get it done.
> 

Realtime and good thread performance are somewhat antithetical.  FIFO
locks perform less well than normal locks.  Lock-free is a better way
to go.  Plus most of the conventional solutions I've see for priority
inversion are really suboptimal.  Basically you get all your RT guarantees
by crippling everything so lower priority threads can't perform better
than high priority threads.

Look at NPTL's futex stuff but don't use futexes, use eventcounts.  Futexes
are somewhat brain damaged but somebody is basing what they think is a neat
hack on it and getting rid of the brain damage means getting rid of the hack.
There's a race condition in the current futex implementation and they will put in
a suboptimal fix rather than get rid of the ability to use the hack.

Also thread cancelation in NPTL at the implementation level is somewhat suboptimal.
That should be done differentlly to make the implementation code somewhat cleaner
and better performing.

And try to avoid preemptive signaling like Linux NPTL does.  Unless Posix mandates
it as a scheduling point.  You might want to cheat on your scheduling policies to
avoid this Posix brain damage if you can.

And the Linux kernel's technique for running a high priority and low priority
hyperthread on the same cpu has to be one of the most brain damaged techniques
I've ever seen anywhere.

Apologies to Alexander for overusing one of his favorite phrases. :)

-- 
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

.