Hi Jakub, Thank you for very prompt response. As I mentioned in our previous discussion, I use fibrils for pthread implementation and I would like to achieve some level of preemptivness. The idea of having a constant number of threads and letting fibrils be distributed amongst these threads really appeals to me (and some preemptivness seems to be necessary for QEMU, although the problem may be somewhere else as usual).
The problem I mentioned manifests when using my implementation of pthread and calling pthread_create lots of times (100000) . Maybe it is also connected with the fact that ids of fibrils aren't unique - it's a pointer to a memory that is likely to be reclaimed by another fibril when the previous one is destroyed. For destroying a joinable pthread(fibril) in pthread_exit that hasn't been joined yet I use fibril_switch(FIBRIL_TO_MANAGER) and later, when the thread is joined I call fibril_destroy on the id of this fibril, that due to my understanding should be dead (not present in any list except fibril_list). I know that fibril_destroy should only be called on a fibril that has never run, but it seems like the same thing that the field clean_after_me does when I would use fibril_switch(FIBRIL_FROM_DEAD). I also thought of a way to avoid doing these unclean calls by merely using a condition variable. That way I could only call fibril_switch(FIBRIL_FROM_DEAD) which would make the whole thing much clearer. I will try that and I will get back to you if I still run into this problem. In that case I will also try to reproduce the same problem on plain fibrils so we can filter out my code. I just wanted to check that I'm not trying to achieve non-achievable. I apologize for such a long email, thank you very much for your help. With regards, Jan 2015-06-03 8:09 GMT+02:00 Jakub Jermar <[email protected]>: > Hi Jan, > > On 06/03/2015 01:38 AM, Jan Mareš wrote: > > I had a discussion here once with Jakub J about fibrils and threads. I > > was told that I can use threads with fibrils, but only as execution > > containers. How would I do it then? What I tried is creating new thread > > and right in the entry point of the thread I call > > fibril_switch(FIBRIL_FROM_DEAD). This seems to work, but when I test it > > more, I run into strange things starting with occasional page faults and > > ending with kernel panic, when trying to kill a process that only > > started 2 threads (1 call to thread_create), but is reporting 3 in the > > top application. > > Hm, I once tried that with VFS and FIBRIL_TO_MANAGER and it seemed to > work well. But there may be some bugs as this is definitely not a well > tested usecase. Would you mind sharing some steps to reproduce / a more > detailed bug report? > > > If I have more threads running some fibrils are sync primitives from > > fibril_synch still good enough to protect shared memory? I'm asking to > > rule out option that I'm doing something fundamentally wrong. Because if > > this is valid way to use threads and fibrils I probably have a race > > condition in my code that I can't find. > > The fibril synchronization primitives use the async_futex in order to be > thread-safe. So this should be ok. > > Jakub > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/listinfo/helenos-devel >
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
