SEH not working with new stack (stack swapping)
in [Win32 Kernel]
|
Prev: Setting Service ACL in Win7 Not Working All the Time?
Next: IIS + ISAPI + EXE + Kernel Namespace + User Accounts + Security Model
From: Jochen Kalmbach [MVP] on 29 Apr 2010 14:35 Hi Hector! > One thing I don't quite understand is the description commonly used that > somewhat implies fibers are "non-preemptive" but cooperative > multitasking when compared to threads. They are not pre-emptive, regarding other fibers on the same thread... If you have 2 fibers, only one fiber can run on ine thread. The fiber will run as long as the *fiber* wants! So it is not pre-emtive, because no other is able to "pre-empt" the fiber. The fiber _must_explizite call "SwitchToFiber" to give an other fiber the chance to run. But, because *you* are reponsible for scheduling, you should knoew that ;) > Of course, they are preemptive otherwise everything will grind down to a > halt. It suggest that the thread fibers themselves are split units of > multitasking work. These units of work must complete or switch to > another task (fiber). This predictable work flow. Yes. It is cooperative-multitasking. > "Threads use pre-emptive scheduling, whereas fibers use > cooperative scheduling." Yes. This is true. In more detail: Fibers are using the tastking-system *you* implement. And normally this is cooperative. There is only _one_ situation in which fibers use pre-emptive multitasking: If you have for each fiber a unique thread ;) but then you do not need fibers, because you only have threads ;) > That doesn't make sense to me. All things are pre-emptied. No. Only threads get pre-empted. And becuase a fiber can only be run in a thread, so a fiber also get pre-empted, but on an other level (OS-level and not app-level). > But since > only one thread fiber with a set can run at a same time, it behaves as a > multi-tasking model. Yes, multi tasking, but cooperative, becuaue the _fiber_ must call "SwitchToFiber". On a pre-emptive sytem, the *scheduler* is switching the threads... -- Greetings Jochen My blog about Win32 and .NET http://blog.kalmbachnet.de/
From: m on 29 Apr 2010 19:21 Okay - so the reason that WIN32 fibers are useless is that you are trying to provide continuations. This is something not supported on Windows, so I wish you luck. I expect that your final solution will be version specific and fragile; but of course this is true of all of your *NIX versions too, so it should be okay. IMHO, the kind of programming that required continuations is only valid in a _very_ few situations and can always be replaced with a more complex, but likely better performing, static algorithm. "olk" <oliver.kowalke(a)gmx.de> wrote in message news:hrb1l6$1k6$03$4(a)news.t-online.com... > m schrieb: >> I am curious why you think that it is a good idea to build this? > > Ofcourse - I got my lib working on several UNIX systems. Only Windows > makes it difficult. > > It >> will be 1) hard; > > probably > > 2) fragile and is probably, like fibers, mostly useless. > > WIN32 Fibers are uselees because not migrateable between threads. > The lib I try to create provides 'continuations'/'coroutines' for C++ > (similiar to features of GO, Python -> call/cc).
From: Hector Santos on 30 Apr 2010 02:05 Jochen Kalmbach [MVP] wrote: > Hi Hector! > >> One thing I don't quite understand is the description commonly used >> that somewhat implies fibers are "non-preemptive" but cooperative >> multitasking when compared to threads. > > They are not pre-emptive, regarding other fibers on the same thread... > > If you have 2 fibers, only one fiber can run on ine thread. The fiber > will run as long as the *fiber* wants! So it is not pre-emtive, because > no other is able to "pre-empt" the fiber. You are missing the subtle point. The system will preempt it just like anything else. The small point I am making is that the descriptions out there, all seem to be pulled from a common place, are mis-leading. They are "preemptable" units of work as much as anything else. So even if you are in control of running your fibers, in a cooperating multitasking nature, a *RUNNING FIBER* is still bound to system level preemption and interrupts. It is misleading to compare a Thread and a Fiber with descriptions that somewhat imply threads can be preempted and fibers are not - that when a fiber is running, they won't be preempted by the system. Fibers are "controlled" units of work within a thread. After listening to Dave Probert's video regarding concRT and UMS, I believe I had the basic idea correct and whats going on with a Fiber: http://channel9.msdn.com/shows/Going%2BDeep/Dave-Probert-Inside-Windows-7-User-Mode-Scheduler-UMS/ I just wanted to know more how you would apply them. At the UM level, overall, the goal is to separate and reduce your work tasks to isolate, minimize/remove locks and bottlenecks and to give you a more predictable work flow, and also if you can "batch" your I/O request needs as much as possible, the better. The reason it spiked my interest is because I'm redesigning many of our client/server based hosting applications, making them more I/O based and the concept of small units of work is now more important here. I can see now where fibers may work, but not fully until I try them and see/measure the benefits, if any. All I can see is the isolation of work where the major benefit is achieved. Thanks -- HLS
From: Jochen Kalmbach [MVP] on 30 Apr 2010 02:57 Hi Hector! > You are missing the subtle point. The system will preempt it just like > anything else. The small point I am making is that the descriptions out > there, all seem to be pulled from a common place, are mis-leading. They > are "preemptable" units of work as much as anything else. That's why is said: And becuase a fiber can only be run in a thread, so a fiber also get pre-empted, but on an other level (OS-level and not app-level). By the way: There should be an example of fiber-based file-copy: http://msdn.microsoft.com/en-us/library/aa230327 -- Greetings Jochen My blog about Win32 and .NET http://blog.kalmbachnet.de/
From: Hector Santos on 30 Apr 2010 05:20
Jochen Kalmbach [MVP] wrote: > Hi Hector! > > By the way: There should be an example of fiber-based file-copy: > http://msdn.microsoft.com/en-us/library/aa230327 Yes, I was going to point this and begin a discussion as to why there are benefits, if any. I mean, to the layman, a CopyFile() or CopyFileEx() is sufficient, but why would one to this do in a fiber version? It has to do with splitting work, one read, one write. By splitting them, you can get benefits of the system to optimized scheduling of threads, but you can only get those benefits with proper delegation of work which is only best determine by you. It has to do as Dave describes with Amdahl's Law - you are only as fast as you weakest link which is normally the serial parts of your system. -- HLS |