From: Daniel Brockman Date: 2005-08-27T08:16:19+09:00 Subject: Re: [ANN] EventLoop 0.0.20050825.1600 Yohanes Santoso writes: > Daniel Brockman writes: > >> You might also ask yourself, do you really *need* to have >> the scheduler arbitrarily switch contexts back and forth? >> Do your event handlers really take that much time to run? >> If so, fine. Otherwise, why not have determinism instead? > > To nitpick, neither pre-emptive threading nor cooperative > threading (of which explicit event handling loop is a form > of) has anything to do with determinism. To nitpick back, I think you overstated that claim a bit. Cooperatively threaded systems are deterministic by default; pre-emptively scheduled ones are probablistic by default. If you write a multithreaded program without keeping synchronization in mind, it is likely to still end up essentially deterministic under cooperative threading. If you are using pre-emptive threading, however, you are very likely to introduce race conditions. So what I'm saying here is that while I agree that the determinism of a correctly written program does not depend fundamentally on the kind of threading in use, I must object to the claim that ``[neither threading model] has anything to do with determinism.'' In a cooperatively multithreaded program, control progresses linearly through the source --- every line of code will be executed immediately after the previous one has finished. In a pre-emptively scheduled one, on the other hand, control jumps around probablistically. Determinism is clearly relevant here, IMHO. But I see your point. I did sort of imply that pre-emptive threading leads to non-determinism, which might not be the fairest way of putting it. Sorry about that. > It is what is being executed in that thread that > determines whether it is deterministic or not. I agree. It's just you don't have to put anything fancy in cooperative threads to make them deterministic, because they already are by default. Unless you put `rand' everywhere. -- Daniel Brockman