On 02/01/2015 03:44 PM, Jan Mareš wrote: > What most likely happens is that the current fibril gets migrated to > another thread when it blocks. This is to be expected due to the way our > async framework works. With the async framework, the normal threads > become something like execution containers, or, if you like, virtual > CPUs, where fibrils can execute. > > One either stays away of the async framework completely and then threads > are the primary execution entities, or one uses async framework and > fibrils are the primary execution entities. Most of the HelenOS uspace > uses fibrils and async framework. The only exception is ns. > > > I think I'm starting to understand what's happening here. The thread id > is stored at the bottom of the stack, when a fibril goes from one thread > to the other, it changes threads stack pointer and thus, when this > thread asks for its id, it receives a different one. But then the whole > THE reference in the kernel is wrong - or at least its thread and cpu > members. Please correct me if I'm wrong, I've tried to find some > materials on the topic of the HelenOS and its fibrils and async > framework, but found only a small description written by MD in some book > touching the topic. I'm keen to read more about this, so I would be > grateful if you could recommend something.
No, this is not about switching threads and their stacks in the kernel - that has worked well. This is about fibrils going to sleep in a per-process userspace global queue from which they are picked by a pretty much random thread that happens to be available at that moment. So a fibril starts executing inside a different thread. That's the reason why you see a different thread ID. You should, however, still observe the same fibril ID. > I realized it's hard to avoid using the async framework in pcut tests, > because libpcut implementation is based on the fibril functionality. I > understand that fibrils use cooperative scheduling. I found GNU portable > threads, which implement pthread as cooperative as well. So there should > be no harm in implementing pthread using the async framework. Yes, fibrils are pretty similar to pthreads, so just stick to fibrils (or model pthreads by fibrils) and ignore threads. Remember that when the async framework is used, threads are merely execution containers. The more execution containers, the more parallelism, provided that you also have multiple CPUs. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
