March 2003 - FFI - Haskell.org

RE: Bound Threads
by Simon Peyton-Jones 18 Mar '03

18 Mar '03

| Maybe, the forkOS/forkIO approach is flawed, but I think we | should only rule it out when we can provide a convincing | example where only the keyword approach would work, and where | we can't use combinators to achieve the same effect. Daan, There has been extended discussion on this stuff, which Wolfgang and Simon and I tried to boil out into a document. It's hard to say exactly what 'safe' or 'bound' exports, or whatever, might mean, so we give a little operational semantics. My hope is that the very same operational-semantic framework would serve to describe your system. Would you like to write its transition rules, in the same style? Then we could compare the two more easily. Without that, I am hard pressed to understand the implications of what you suggest, just as I was hard pressed to understand Wolfgang's proposal till we had it specified. You can find the document in the CVS respository in haskell-report/ffi/threads.tex Simon

1 0

Re: Bound Threads
by Wolfgang Thaller 17 Mar '03

17 Mar '03

(I keep forgetting to correctly fill out the To: and Cc: fields before sending my reply... so here's the copy that should have been sent to the list 10 minutes ago...) Daan Leijen wrote: > Hi Wolfgang, > > I feel like you are beating my proposal to death here, and I find it > hard to > react individually to all your remarks. Sorry, maybe I shouldn't shoot all my arguments at you at once :-) > I'll try to focus on the main issue: > > You are worried that the forkOS and forkIO distinction is too > primitive and > that it rule out sophisticated scheduling on SMP processors for > example. That is closely related to the point that I don't want implementation details (that several Haskell threads can run in one OS thread) to be part of a defined interface that has to be supported by all implementations. My main point is probably my strong phobia of "safe" calls: they are not safe to use. FFI newbies are repeatedly getting bitten by the fact that "safe" calls block everything else. There is no "natural" reason for a call to block other threads, it's a consequence of an implementation detail (lightweight threads). The intention behind threadsafe is to make this implementation detail invisible, and therefore harmless. The forkOS/forkIO proposal seems to rely on having foreign calls that block other threads (that run in the same OS thread)... or doesn't it? > Maybe, the forkOS/forkIO approach is flawed, but I think we should > only rule it out when we can provide a convincing example where only > the keyword approach would work, and where we can't use combinators to > achieve the same effect. That's unfair ;-) --- I could also claim the reverse and say that we stick with threadsafe/bound until we have a convincing example... Using combinators sounds good, but there are things where combinators are not automatically the best choice (we're usually not using combinators to implement lazyness, either), and we don't know yet whether this is the case here or not. So let's just get on with the discussion.... > About the example: > [snip] > That is amazing :-) [...] Well, of course, it's "none of your business" to know. Different Haskell runtimes could use completely different schemes, and you wouldn't even notice. In GHC, the second OS thread is spawned earlier, the first time a threadsafe call is made. When the threadsafe call is made, GHC a) makes sure that there is a second OS thread available (some overhead the first time) and b) makes sure that all non-bound [in the current implementation: all] Haskell threads are executed by the second OS thread from now on. Now if a bound callback is invoked [not yet implemented], the bound callback is executed in the thread that the wrapper was called in (the first OS thread). All other Haskell threads (if any) continue to run in the second OS thread. If forkIO is called, the new Haskell thread is just added to the list of threads to be run by the second OS thread, no new OS thread has to be spawned, and forkIO doesn't have to know about threadsafe or about bound. If a non-bound callback is invoked [available now in the CVS HEAD], the callback is executed along with the other background Haskell threads in the second OS thread. > Since the RTS can't guess whether to use new OS threads or not at > forkIO, I assumed > that you could mark "wrapper" functions (callbacks) with a > "threadsafe" attribute. If > this is not the case, I don't understand how the implementation could > work in this particular > example. It doesn't need to guess, "threadsafe" is just for imports, and it works anyway. See above, and if I haven't explained it clearly, try http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/rts-libs/multi- thread.html (which I really should update, it's outdated), or ask again. Maybe we need a more exact specification of how forkOS/forkIO should behave, especially with respect to foreign calls blocking other threads. Could you elaborate on how you would expect "normal" (safe) foreign calls to behave in different situations? Cheers, Wolfgang

2 2

Re: Bound Threads
by mike V 16 Mar '03

16 Mar '03

For what it is worth I favour Daan's approach, adding keywords to a language seems to want for a sufficiently rich formalism/framework. >3) maybe we should also add "forkUnbound" that forks a haskell thread > >that can automatically be moved between OS threads. In the spirit of searching for the most basic primitives - why not instead define a primitive for moving haskell threads from os thread, as this primitive seems to be required in any case in order to effect the "automatic" movement between threads. Such a primitive would allow alternative thread management strategies to be defined in haskell. forkUnbound could then be implemented by registering the haskell thread with the thread manager etc... such a strategy would require explicitly identifying os threads - making them almost first class, so to speak - is this bad ? whilst ... > We never want to specify what OS thread is running a particular > Haskell thread. in order to define strategies where the above is true, I believe we do need to be explicit. These strategies can either be implemented by the rts, or in a library. I think that the latter is better in the sense of more open. explicit movement of Haskell threads between OS threads could potentially be extended to thread migration between processes? >* "forkOS" doesn't have to use a new OS thread to run Haskell threads, just >when calling a foreign function, so it would work on Hugs too for example. >(as explained why complicate matters, if forkOs/forkNative is supposed to fork a native thread then why introduce exceptions, as is not forking of a native thread part of the meaning of the operation? _________________________________________________________________ MSN Instant Messenger now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp

1 0

RE: Bound Threads
by Simon Marlow 14 Mar '03

14 Mar '03

> I have just spend some time reading through all the > discussions and the > new "threads" document and I would like to propose the > addition of a new library function. > > > forkOS :: IO () -> IO ThreadID > > The function "forkOS" forks a new Haskell thread that runs in > a new OS (or > native) thread. With this, I also propose that "forkIO" > always runs a Haskell thread in the same OS thread that the > current Haskell thread runs in. > (i.e. "forkIO": same OS thread, "forkOS": new OS thread) I'd like to point out a concept that I think is being missed here: We never want to specify what OS thread is running a particular Haskell thread. why not? Because (a) it doesn't matter: the programmer can never tell, and (b) we want to give the implementation freedom to spread Haskell threads across multiple OS threads to make use of multiple real CPUs. But the programmer CAN tell, you scream! How can the programmer tell? Only by calling foreign functions. The point is that you want to specify which OS thread is used to invoke a foreign function, NOT which OS thread is used to execute Haskell code. The semantics that Simon & I wrote make this clear. If we keep thinking like this, then implementations like Hugs can be single-threaded internally but switch OS threads to call out to foreign functions, and implementations like GHC can be multi-threaded internally and avoid switching threads when calling out to foreign functions. > Using the new primitive, we can view the new "threadsafe" keyword as > syntactic sugar: > > > foreign import threadsafe foo :: Int -> IO Int > > ===> > > > foo :: Int -> IO Int > > foo i = threadSafe (primFoo i) > > > > foreign import "foo" primFoo :: IO Int > > where > > > threadSafe :: IO a -> IO a > > threadSafe io > > = do result <-newEmptyMVarforkOS (do{ x <-io; putMVar result x }) > > getMVar result This forces a thread switch when calling a threadsafe foreign function, which is something I think we want to avoid. I'm basing this on two assumptions: (a) switching OS threads is expensive and (b) threadsafe foreign calls are common. I could potentially be wrong on either of these, and I'm prepared to be persuaded. But if both (a) and (b) turn out to be true, then worse is worse in this case. Cheers, Simon

3 3

Re: Bound Threads
by Wolfgang Thaller 14 Mar '03

14 Mar '03

> I have just spend some time reading through all the discussions and the > new "threads" document and I would like to propose the addition of a > new library function. > >> forkOS :: IO () -> IO ThreadID Something like that is already in the proposal, only it's currently called forkBoundThread and it doesn't return the ThreadID (that can be changed, though). > With this, I also propose that "forkIO" always runs a Haskell thread > in the same OS thread that the current Haskell thread runs in. > (i.e. "forkIO": same OS thread, "forkOS": new OS thread) In the proposal we wrote: "The specification shouldn’t explicitly require lightweight “green” threads to exist. The specification should be implementable in a simple and obvious way in haskell systems that always use a 1:1 correspondence between Haskell threads and OS threads." The idea was that lightweight ("green") threads are an optimization only (do they have any other advantage?), not a language feature, and that implementations of Haskell should not be forced to support a complex thread management system. Your proposal obviously contradicts this. What is the advantage of explicitly requiring one OS thread to execute (the foreign calls made by) several Haskell threads? So far, I was only able to think of two possible situations: a) The foreign functions don't care what thread they are called from In that case, I would like the implementation to run my Haskell threads in the most efficient way possible. Currently, that means scheduling them all in one OS thread, but that is an implementation detail that I don't want to care about when I'm writing a normal application. On a four-processor-SMP machine, the most efficient way is to run them simultaneously in four OS threads (no implementation currently supports this, but there's experimental code in the GHC repository). b) The foreign functions do care what thread they are called from In that case I want the implementation to have an exact correspondence between Haskell threads and OS thread. I just want to think about "one thread", and I don't want to manage some correspondence between Haskell threads and OS threads manually. > Using the new primitive, we can view the new "threadsafe" keyword as > syntactic sugar: > >> foreign import threadsafe foo :: Int -> IO Int > > ===> > >> foo :: Int -> IO Int >> foo i = threadSafe (primFoo i) >> >> foreign import "foo" primFoo :: IO Int > > where > >> threadSafe :: IO a -> IO a >> threadSafe io >> = do result <-newEmptyMVarforkOS (do{ x <-io; putMVar result x }) >> getMVar result That looks dangerous: I want to call both threadsafe imports and unsafe imports from a "bound thread", and I expect all foreign calls from a bound thread to be executed from the same OS thread (by the definitioon of a "bound thread"). This implementation of "threadsafe" always uses another (new or pooled) OS thread for the threadsafe call. >> getOSThread :: ThreadID -> OSThreadID >> forkIOIn :: OSThreadID -> IO () -> IO ThreadID Why should the RTS do inter-OS-thread messaging for us? > I have the feeling that it is not difficult to implement "forkOS" and > family > once the runtime system has been upgraded to support multiple OS > threads. > Wolfgang, you seem to be the expert on the OS thread area, would it be > hard? It would definitely more difficult to implement in GHC than the current proposal, but it could be done. In fact I think that implementing it would be more fun for me than having to use it afterwards. > I am not saying that we should discard the "threadsafe" keyword as it > might > be a useful shorthand, but I think that it is in general a mistake to > try to keep the management of OS threads implicit -- don't use new > keywords, add combinators to implement them! Management of OS threads _should_ be kept implicit. Ideally, the user should never notice that the GHC runtime is using green threads internally. > I feel that the following has happened; urk, we need some way of > keeping haskell threads running while calling C; we add "threadsafe"; > whoops, sometimes > a function expects that it is run in the same OS thread; we add > "bound"; whoops, sometimes functions expect to be run from a specific > OS thread... unsolved?? Not unsolved. Use Control.Concurrent.Chan :-) > Before we know it, we have added tons of new keywords to solve the > wrong problem. The problem being, that some Haskell implementation try to optimize concurrency by doing the scheduling themselves. We have to provide hints (threadsafe and bounds) to the implementation to specify just how much it is allowed to optimize. We should never be required to explicitly do the "optimization" in the source code. It will break with SMP implementations (which I expect to be using in a few years), because different optimizations are required - suddenly it will be desirable to have multiple OS threads for performance reasons. > Maybe it is time to take a step back and use a somewhat lower level > model with > two fork variants: "forkIO" (in the same OS thread) and "forkOS" (in a > new OS thread). > It seems that none of the above problems occur when having explicit > control. > In general it seems that OS threads are a resource that is too subtle > to be managed automatically as they have a profound impact on how > libraries are used and applications are structured. My recipe: 1) Mark all your foreign imports as threadsafe 2) Mark foreign imports that are guaranteed to only need a short amount of time (<50ms at most, I'd say) and that won't call back to Haskell, as unsafe 3) Just pretend that every Haskell thread is an OS thread 4) If you're using libraries that rely on thread-local state (and therefore can find out that point 3 might not be strictly true), add "bound" to your foreign exports or wrap your IO actions in forkBoundThread. I don't see any remaining problems, and it looks simpler to me than managing Haskell threads and OS threads explicitly. OK, enough talking about why I like my ideas better than yours ;-) , I still have a few questions: What would a safe foreign import do in your proposal? What other Haskell threads would be blocked when I call a safe foreign import? When would they be unblocked again? What happens when the foreign import calls back to Haskell? Or would they be blocked at all? For A Haskell implementation that runs in one thread and just uses separate threads for foreign calls, it may be natural to not block until somebody tries to make another foreign call in the same OS thread... And how would the whole thing work in a SMP Haskell system? When writing programs and libraries, how would I manage the complex interactions that could happen? How can a library make use of forkIO if it doesn't know what _other_ Haskell threads might be running in the same OS thread? Currently, I can also use the threadsafe attribute for long calculations outside the IO monad, i.e. foreign import ccall threadsafe doSomeTerriblyComplicatedCalculation :: Double -> Double If one Haskell thread evaluated this, all other Haskell threads would keep running. Do we need to use unsafePerformIO again in your proposal? Simon Marlow wrote: > I'm basing this on two assumptions: (a) switching OS threads is > expensive and (b) threadsafe foreign calls are common. I could > potentially be wrong on either of these, and I'm prepared to be > persuaded. But if both (a) and (b) turn out to be true, then worse is > worse in this case. a) Is probably true. If it was absolutely wrong, we could do away with all the complexity, use one OS thread for each Haskell thread and shorten the GHC RTS by a few thousand lines... b) Personally, I would want to use them for every foreign call that is not guaranteed to finish within, say, 50ms, so it will certainly be true for _my_ programs. I would expect all libraries that I want to use to do this, too, because otherwise my program might unexpectedly be blocked by threads spawned by the library. Cheers, Wolfgang

1 0

RE: Bound Threads
by Simon Peyton-Jones 14 Mar '03

14 Mar '03

[I've updated the "Semantics for foreign threads" document by re-ordering the sections a bit. It'd benefit from having a bit more formal syntax. No one has commented a single word on the operational semantics. I don't know whether that's because it's so clear that no discussion is needed, or so opaque that no discussion is possible.] | > I must admit that I can't remember the | > exact semantic distinction between those "safe" and "threadsafe" | | The problem is, nobody does... the original implementation didn't work | in all cases. The original implementation made "safe" calls block all | other haskell threads in some cases, and crashed in other cases. | "Threadsafe" means that calling the foreign import shouldn't block or | otherwise disturb other haskell threads. "Safe" means... well... almost | nobody seems to know, and still fewer people agree on it. | In the current "HEAD", there is no difference between threadsafe and | safe. If someone comes up with a clear specification of why and how | "safe" should be different from threadsafe, things might change again. Indeed, the semantics in the "semantics of bound threads" document makes no distinction between "safe" and "threadsafe" either. The original intention was this: a threadsafe foreign call must not block Haskell threads, even if the foreign call blocks in foreign land. a safe call is not required to obey this constraint The motivation was that thread-safety might require more admin (e.g. relinquishing the lock on the main Haskell heap), and this admin might be costly. A side consequence of GHC's implementation (albeit not of the above specification) is that no Haskell threads progress during a safe call (unless it provokes a call-back..?). I recall that some people actually started to rely on this, though it was never intended as part of the spec. I think Wolfgang is saying that the apparent efficiency gain of not requiring thread-safety is illusory, and so we can abolish the safe/threadsafe distinction. I think that would be a very worthwhile gain. Does anyone disagree with this? Simon

4 4

Re: [GUI] GUIs and events (was: Re: Concurrency)
by Wolfgang Thaller 13 Mar '03

13 Mar '03

Glynn Clements wrote: > Wolfgang Thaller wrote: > >> 2) CGA implementations should automatically do all necessary >> synchronization so that the CGA fully supports concurrency even if the >> backend library does not. > > I suspect that this might be a bad idea, and I'm not totally sure that > it's even possible. I think that it would be better to defer this > decision until the feasibility can be assessed. While different implementations might in some cases be slightly more complex than just using locks, I don't see why it should be impossible. After all, thread-safe toolkits are not new. Do you have any specific problems in mind? Also, it should be noted that this feature is important: Unless we have this or an equivalent, it will _not_ be possible to use concurrent Haskell for writing GUI programs. Of course, we could still agree that it is a goal, add something like "unless it turns out to be infeasible" and then revisit the issue later. Cheers, Wolfgang

2 2

Kontakt Lenste yeni yil firsati 1 Kutu Lens 35 Milyon USTELIK ADRESE TESLIM KACIRMAYIN___6357474__
by ffi 09 Mar '03

09 Mar '03

En ucuz lensler icin lutfen tiklayin. Bir telefonla adrese teslim. http://www.akdenizgoz.com Akdeniz Goz Merkezi Fevzipaþa No:73 Fatih 0 212 635 74 74 Listeden cikmak icin remove(a)akdenizgoz.com adresine bos mail gonderiniz

1 0

RE: Bound Threads
by Simon Peyton-Jones 07 Mar '03

07 Mar '03

| First let me outline my current understanding of what 'bound' means. | Consider the following scenario: | | Haskell program is running in OS thread 't1' | Haskell program calls C function 'foo'. | 'foo' forks a new OS thread 't2'. | In parallel: 't1' calls Haskell function 'f1' and | 't2' calls Haskell function 'f2' | 'f1' calls C function 'g1' | 'f2' calls C function 'g2' | | My understanding is that 'bound' requires that 'g1' be executed by | thread 't1' and that 'g2' be executed by thread 't2'. You didn't say where the program mentions 'bound'! I tried very hard to give a precise description of what bound threads are, in haskell-report/ffi/threads.tex. (Wolfgang circulated a PDF recently.) Does that specification make sense? Does it answer your question? (If not, we should improve it.) I'm sure it would be improved by examples -- would you like to add one? Simon

1 0

Finalizers, again!
by Manuel M T Chakravarty 06 Mar '03

06 Mar '03

I have just read Hans Boehm's POPL paper on finalizers. His suggestion for the use of finalizers in single-threaded systems is to provide a `runFinalizers' routine, instead of relying on the asynchronous execution that, as established, requires support for concurrency. I am not sure whether we have given this option really serious consideration. Why may this option be interesting? It may allow us to have Haskell finalizers after all. As Boehm explains, ``finalizers generally fall into two categories: Those that simply deallocate operating system resources and those that touch other user data structures.'' It seems that we currently, probably due to our FFI bias, concentrate on the former kind. The main benefit of Haskell finalizers, apart from convenience, is the ability to process Haskell structures. As I understand Boehm, we might adopt the following design: * Finalizers are normal Haskell routines. * When the GC discovers that a finalizer becomes enabled, it is added into a list of enabled finalizers (but not run in a single-threaded system). * When the routine runFinalizers :: IO () is called, it runs the finalizers in the list of enabled finalizers one after the other. * Systems supporting pre-emptive concurrency *may* run finalizers at any time after they become enabled, but they must run them when `runFinalizers' is called (similar to `performGC'). An attractive property of this design is that it provides a smooth transition from single-threaded systems to systems providing pre-emptive concurrency. The requirement to invoke `runFinalizers' explicitly might not be too burdensome in practice as code making heavy use of the FFI and finalizers probably spends a lot of time in the IO monad with the opportunity to insert calls to `runFinalizers'. Opinions? Cheers, Manuel PS: Sorry for bringing finalizers up again, but if there is an opportunity to improve the current design, I think, we should consider it.

2 1