Re: Native Threads in the RTS
I wrote: > [...] Note that the fact that only one Haskell thread may execute at a > time remains unchanged. [...] Sven Panne wrote: I haven't thought very deeply about your proposal yet, but I don't understand the remark above: What about e.g. a multi-processor Solaris machine (where pthreads work as intended, [...] We can't currently allow several Haskell threads to really run simultaneosly [e.g. on two separate processors, or preemtively scheduled on a single processor], because they always mutate the same global heap. Currently, GHC switches its green threads only at times when the heap is in a defined state [not truly preemptively]. There seems to be some SMP support in the RTS, I don't know if it ever worked. If anyone wants to fix/finish it, that would be great, but it's not what I'm proposing here. My proposal is only a minimum solution intended to resolve the inherent incompatibility between the "threaded RTS" and libraries like OpenGL, which require thread-local-state. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Silly question about IORefs and MVars
Hello, I have a silly question about IORefs and MVars. When do we have to use MVars if a var is accessed by multiple threads. In fact, I wonder why IORefs updates aren't safe : it seems that preemptive scheduling takes place during memory allocation and I can't see where there could be an allocation (and so a switch) in a read or a write of an IORef. Related question : how less performant is a MVar comparated to simple ref. best regards, Nicolas Oury ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
On Sun, 17 Nov 2002 12:23:06 +0100 Sven Panne wrote: >> Nevertheless, you make a good point: Better support for "real" >> multi-threading is definitely an area where I'd like to see some >> improvement for the next non-patchlevel release of GHC. I'm still >> unconvinced that the current optional RTS support for mixed >> green/native threads is the right way to go. It looks to me like a >> workaround for poor OS support for really lightweight threads. On Sun, Nov 17, 2002 at 11:33:44AM +, Duncan Coutts wrote: > Which of course has been improving greatly recently - on Linux at least. > The 2.6 kernel will apparently have threading on par with Solaris. In > fact, the next Linux pthreads library looks as though it will be based > on a 1:1 model rather than a M:N model because it is simpler and (with > the recent threading improvements) performs better. > So that means that all of ghc's major platforms (Solaris, Linux, Win32) > will have good OS thread support in the near future. 1:1 threading is inferior by virtue of resource scalability on 32-bit machines. This is not the final word. Bill ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
On Sun, 17 Nov 2002 12:23:06 +0100 Sven Panne <[EMAIL PROTECTED]> wrote: > Nevertheless, you make a good point: Better support for "real" > multi-threading is definitely an area where I'd like to see some > improvement for the next non-patchlevel release of GHC. I'm still > unconvinced that the current optional RTS support for mixed > green/native threads is the right way to go. It looks to me like a > workaround for poor OS support for really lightweight threads. Which of course has been improving greatly recently - on Linux at least. The 2.6 kernel will apparently have threading on par with Solaris. In fact, the next Linux pthreads library looks as though it will be based on a 1:1 model rather than a M:N model because it is simpler and (with the recent threading improvements) performs better. So that means that all of ghc's major platforms (Solaris, Linux, Win32) will have good OS thread support in the near future. Duncan ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
Wolfgang Thaller wrote: > [...] I propose adding something like > > forkNativeThread :: IO () -> IO () > > which forks a new Haskell thread that has its own OS thread to execute > in. Note that the fact that only one Haskell thread may execute at a > time remains unchanged. [...] I haven't thought very deeply about your proposal yet, but I don't understand the remark above: What about e.g. a multi-processor Solaris machine (where pthreads work as intended, not the rather poor stuff currently shipped with Linux)? In such an environment there are often multiple processors executing different threads (or LWPs, or whatever you call it) of the same process simultaneously. Perhaps I misunderstood something here... :-} Nevertheless, you make a good point: Better support for "real" multi-threading is definitely an area where I'd like to see some improvement for the next non-patchlevel release of GHC. I'm still unconvinced that the current optional RTS support for mixed green/native threads is the right way to go. It looks to me like a workaround for poor OS support for really lightweight threads. Cheers, S. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
