I must point out the fallacy of the subject line (not to mention the grammatical incorrectness) - There is an overwhelming amount of evidence that threads _CAN_ be implemented as a library. But I think the point of the article is that the use of a programming language with threading built in, is a better venue for enforcing correct thread behavior, than a general purpose language, such as C, in which you have to understand a great deal about a parallel run-time to keep things working correctly.
This is not a new concept. Anyone here remember Ada?
When I learned Ada, I was working for a real-time company that had a platform with support for Ada. The Ada run-time has a scheduler (as all threading run-times require), which was implemented in pthreads, which also had a run-time, which was implemented with ligh-weight kernel threads on the real-time OS. So, to be able to get the scheduling to work the way you wanted to, you needed to manage your thread a three different levels. Ugh.
But this brings up a the point (might as well slaughter English also): Threads ain't a Library and Threads ain't a Language. The essence of threading is found in a run-time scheduler, which is an executable that runs either inside an OS kernel, or runs in user space. That scheduler could be written in FORTRAN for all we know, but it exists as an executable piece of code. The "Threads" themselves are nothing more than data structures that contain information the scheduler can use to manage them and run them in some order or priority. Sometimes these can be run on parallel hardware and a good thread run-time will know how to do this, either through or in the OS kernel.
So, the programming interface is what is being discussed. At the heart of it, the API does little more than provide a way to modify the data structures that contain the threading information and communicate with the treading run time. This can be done with a library of subroutines, or a compiler that compiles a parallel language into code that modifies these data structures and communicates with the run-time.
One approach hands you a gun and asks that you learn how to use it and the other provides you with a restricted environment with lots of red-tape to insures you make no mistakes.
When it comes to software, it is a battle of survival. As a developer, I favor standard methods that allow me to develop cross platform applications without the need for platform specificity. It looks like HP labs is reinventing a wheel and that's OK. If it becomes a widely used standard I'll adopt.
Otherwise my faith in it goes as far as the credibility of the subject line.
-don
On 5/11/06, Chris Hanson <[EMAIL PROTECTED]> wrote:
I'm not really experienced/qualified enough to judge the merits of this, but since
threading in OSG has been a critical issue, I thought I'd bring it to the attention of
others and see what they thought.
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html
Abstract: In many environments, multi-threaded code is written in a language that was
originally designed without thread support (e.g. C), to which a library of threading
primitives was subsequently added. There appears to be a general understanding that this
is not the right approach. We provide specific arguments that a pure library approach, in
which the compiler is designed independently of threading issues, cannot guarantee
correctness of the resulting code. We first review why the approach almost works, and then
examine some of the surprising behavior it may entail. We further illustrate that there
are very simple cases in which a pure library-based approach seems incapable of expressing
an efficient parallel algorithm. Our discussion takes place in the context of C with
Pthreads, since it is commonly used, reasonably well specified, and does not attempt to
ensure type-safety, which would entail even stronger constraints. The issues we raise are
not specific to that context.
--
Chris 'Xenon' Hanson aka Eric Hammil | http://www.3DNature.com/ eric at logrus
"I set the wheels in motion, turn up all the machines, activate the programs,
and run behind the scenes. I set the clouds in motion, turn up light and sound,
activate the window, and watch the world go 'round." -Prime Mover, Rush.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
