lkml.org 
[lkml]   [2005]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: what's next for the linux kernel?
On Tue, Oct 04, 2005 at 07:04:35PM +0400, Nikita Danilov wrote:
> Luke Kenneth Casson Leighton writes:
> > On Sun, Oct 02, 2005 at 08:27:45PM -0500, Chase Venters wrote:
> >
> > > The bottom line is that the application developers need to start being clever
> > > with threads.
> >
> > yep! ah. but. see this:
> >
> > http://lists.samba.org/archive/samba-technical/2004-December/038300.html
> >
> > and think what would happen if glibc had hardware-support for
> > semaphores and mutexes.
>
> Let me guess... nothing?

interesting.

> Overhead of locking depends on data-structures
> used by application/library and their access patterns: one thread has to
> wait for another to finish with the shared resource.

yes.

> locking in hardware is going to change nothing here (barring really
> stupid implementations of locking primitives). Especially as we are
> talking about blocking primitives, like pthread semaphore or mutex: an
> entry into the scheduler will by far outweigh any advantages of
> raw-metal synchronization.

so what would, in your opinion, be a good optimisation?

the references i found (just below) are to tool chains or research
projects for code or linker-level analysis and parallelisation tools.

what would, in your opinion, be a good way for hardware to assist
thread optimisation, at this level (glibc)?

assuming that you have an intelligent programmer (or some really good
and working parallelisation tools) who really knows his threads?



> > http://www.ics.ele.tue.nl/~sander/publications.php
> > http://portal.acm.org/citation.cfm?id=582068
> > http://csdl.computer.org/comp/proceedings/acsd/2003/1887/00/18870237.pdf
> >
> > to get the above references, put in "holland parallel code
> > analysis tools" into google.com.
>
> PS: I wonder why Luke Kenneth Casson Leighton, Esq., while failing to

can i invite you to consider, when replying to these lists, to consider
instead of treating it as a location where you can piss over anyone
that you do not believe to be in any way your equal or in fact the equal
of anyone, to instead consider the following template for your replies:

okay, right.
* i do/don't get what this guy is saying.
* i do/don't have an alternative idea (here it is / sorry)
* here's what's wrong / right with what he's saying.
* here's where it can/can't be done better.

the bits that are missing from your reply are:

* "you do/don't get where i'm going with this"
* you haven't specified an alternative idea
* you've outlined what's wrong but not what's right
* you haven't specified how it can be done better.

i therefore conclude that you are bully. a snob.

i _really_ detest bullying - and that's what you are doing.

intellectual bullying.

stop it.

so i sent some messages saying "i think the kernel developers could be
wrong in their design strategy" so FRIGGIN what?

prove me right or prove me wrong.

or shut up, or add my email address to your killfile.

_don't_ be an intellectual snob.

l.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-10-04 18:19    [W:3.108 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site