bwh: (Default)
[personal profile] bwh
Before I forget about it, here are the materials I prepared for my talk "Multithreading: why and how we should use it". I know I didn't present very well, but hopefully the links will give you a bit more explanation.

Date: 2006-05-15 08:38 am (UTC)
ext_8103: (geek)
From: [identity profile] ewx.livejournal.com
  - Server: thread pool, one kernel thread per processor
    - Harder to write - application needs its own scheduler

Isn't this traditionally the job of the threading library?

Date: 2006-05-15 10:29 pm (UTC)
From: [identity profile] womble2.livejournal.com
You mean like Solaris's N-on-M threading? I thought that hadn't worked out so well in practice.

Date: 2006-05-16 08:34 am (UTC)
ext_8103: (Default)
From: [identity profile] ewx.livejournal.com
That's what I'm thinking of. I've no idea how it works in practice but it sounds like you're asking for the same thing but with the added effort of having to do the user threading half of the job yourself.

Date: 2006-05-16 06:27 pm (UTC)
From: [identity profile] womble2.livejournal.com
I think the problem is that to schedule work units (or whatever you want to call them) properly you need to know more about what the program is doing than a POSIX threads (or Solaris threads) library does. That's not necessarily something that needs to be done differently for each application, though. There are various frameworks that support it, such as J2EE.

Date: 2006-05-15 09:51 am (UTC)
From: (Anonymous)
I tried to watch it, without success :(

Date: 2006-05-15 09:52 am (UTC)
From: [identity profile] sunflowerinrain.livejournal.com
that was me, disloggedin again *sigh*

February 2011

S M T W T F S
  12345
6789101112
13141516171819
20212223 242526
2728     

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 17th, 2017 05:56 am
Powered by Dreamwidth Studios