> Is there a user-space implemenation (library?) for
> coroutines that would work from C?
Here is another one:
http://oss.sgi.com/projects/state-threads/
Regards,
Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Any chance this or the equiv could become part of glibc?
This seems a very handy abstraction, in many apps
threads would then really only be needed for true parallelism.
Michael Rothwell wrote:
> Try this:
>
> http://lecker.essen.de/~froese/coro/
>
> -M
>
> On 16 Jun 2001 14:33:50 -0400, Ru
Try this:
http://lecker.essen.de/~froese/coro/
-M
On 16 Jun 2001 14:33:50 -0400, Russell Leighton wrote:
>
> Is there a user-space implemenation (library?) for coroutines that would work from C?
>
>
> Alan Cox wrote:
>
> > > Can you provide any info and/or examples of co-routines? I'm curio
PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of bert hubert
Sent: Friday, June 15, 2001 12:32 AM
To: Alan Cox
Cc: Kip Macy; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: threading question
On Thu, Jun 14, 2001 at 07:28:32PM +0100, Alan Cox wrote:
> There are really only two reasons
On Thu, Jun 14, 2001 at 04:42:29PM -0600, [EMAIL PROTECTED] wrote:
> 2. The main thread sets up the data (which are global) and then signals
> that there is work to be done on the same condition variable. The first
> thread to get awaken takes the work. the remaining threads keep waiting.
For cur
> Hello,
>
> I have implemented thread pooling (with an environment variable
> where I can give the number of threads to be created). Results:
>
> 1. Linux, no change in the times (not under 2.2.x or 2.4)
[snip]
> I am now pretty much inclined to believe that it is either a) hardware
> issue (some
Hello,
I have implemented thread pooling (with an environment variable
where I can give the number of threads to be created). Results:
1. Linux, no change in the times (not under 2.2.x or 2.4)
2. SGI/Solaris/OSF/1: times decrease when the number of threads matched
the number of processors avail
bert hubert wrote:
>
>
> I see lots of people only using:
> pthread_create()/pthread_join()
> mutex_lock/unlock
> sem_post/sem_wait
> no signals
>
> My gut feeling is that you could implement this subset in a way that is both
> fast and right - although it would
bert hubert wrote:
> > from Larry McVoy's home page attributed to Alan Cox illustrates this
> > reasonably well: "A computer is a state machine. Threads are for people
> > who can't program state machines." Sorry for not being more helpful.
>
> I got that response too. When I pressed kernel peop
EMAIL PROTECTED]>@vger.kernel.org on 06/13/2001 01:31:39 PM
Sent by: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: threading question
On Tue, Jun 12, 2001 at 12:06:40PM -0700, Kip Macy wrote:
> This may sound like flamebait, but its not. Linux threads are basically
> just proce
On Tue, Jun 12, 2001 at 12:06:40PM -0700, Kip Macy wrote:
> This may sound like flamebait, but its not. Linux threads are basically
> just processes that share the same address space. Their performance is
> measurably worse than it is on most commercial Unixes and FreeBSD.
Thread creation may be
Solaris has pset_create() and pset_bind() where you can bind LWPs to
specific processors, but I doubt this works on anything else
Best regards,
Ognen
On Wed, 13 Jun 2001, Philips wrote:
> BTW.
> Question was poping in my mind and finally got negative answer by my mind ;-)
>
>
"J . A . Magallon" wrote:
>
> On 20010613 Kurt Garloff wrote:
> >
> > What I do in my numerics code to avoid this problem, is to create all the
> > threads (as many as there are CPUs) on program startup and have then wait
> > (block) for a condition. As soon as there's something to to, variables
On 20010613 Kurt Garloff wrote:
>
> What I do in my numerics code to avoid this problem, is to create all the
> threads (as many as there are CPUs) on program startup and have then wait
> (block) for a condition. As soon as there's something to to, variables for
> the thread are setup (protected
On Tue, Jun 12, 2001 at 01:07:11PM -0600, [EMAIL PROTECTED] wrote:
> due to the nature of the problem (a pairwise mutual alignment of n
> sequences results in mx. n^2 alignments which can each be done in a
> separate thread), I need to create and destroy the threads frequently.
>
> I am not reall
Hi!
> I am a summer student implementing a multi-threaded version of a very
> popular bioinformatics tool. So far it compiles and runs without problems
> (as far as I can tell ;) on Linux 2.2.x, Sun Solaris, SGI IRIX and Compaq
> OSF/1 running on Alpha. I have ran a lot of timing tests compared t
On Tue, Jun 12, 2001 at 03:25:54PM -0400, Russell Leighton wrote:
> Any recommendations for alternate threading packages?
Does NSPR use native methods (ie, clone), or just ride on top of pthreads?
What about the gnu threading package?
mrc
--
Mike Castle [EMAIL PROTECTED] www.net
In article <[EMAIL PROTECTED]> you
wrote:
> For heavy threading, try a user-level threads package.
Sure, userlevel threading is the best way to get SMP-scalability...
--
Of course it doesn't work. We've performed a software upgrade.
-
To unsubscribe from this list: send the line "unsubscribe l
Any recommendations for alternate threading packages?
Alexander Viro wrote:
> On Tue, 12 Jun 2001, Kip Macy wrote:
>
> > implementation of threads is not an accidental oversight, threads are not
> > looked upon favorably by most of the core linux kernel hackers. A quote
>
> s/threads/POSIX th
On Tue, 12 Jun 2001, Kip Macy wrote:
> implementation of threads is not an accidental oversight, threads are not
> looked upon favorably by most of the core linux kernel hackers. A quote
s/threads/POSIX threads/.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Tue, Jun 12, 2001 at 01:07:11PM -0600, [EMAIL PROTECTED] wrote:
> Hello,
>
> due to the nature of the problem (a pairwise mutual alignment of n
> sequences results in mx. n^2 alignments which can each be done in a
> separate thread), I need to create and destroy the threads frequently.
>
> I
For heavy threading, try a user-level threads package.
-Kip
On Tue, 12 Jun 2001 [EMAIL PROTECTED] wrote:
> Hello,
>
> due to the nature of the problem (a pairwise mutual alignment of n
> sequences results in mx. n^2 alignments which can each be done in a
> separate thread), I
This may sound like flamebait, but its not. Linux threads are basically
just processes that share the same address space. Their performance is
measurably worse than it is on most commercial Unixes and FreeBSD.
They are not, or at least two years ago, were not POSIX compliant
(they behaved badly wi
Hello,
due to the nature of the problem (a pairwise mutual alignment of n
sequences results in mx. n^2 alignments which can each be done in a
separate thread), I need to create and destroy the threads frequently.
I am not really comfortable with 1.4 - 1.5 speedups since the solution was
intended
In article <[EMAIL PROTECTED]> you wrote:
> On dual-CPU machines the speedups are as follows: my version
> is 1.88 faster than the sequential one on IRIX, 1.81 times on Solaris,
> 1.8 times on OSF/1, 1.43 times on Linux 2.2.x and 1.52 times on Linux 2.4
> kernel. Why are the numbers on Linux machi
25 matches
Mail list logo
