|
|
Threads-Devel : |
From: Edd Dawson (lists_at_[hidden])
Date: 2008-05-21 20:27:26
Hi Vicente,
On 21 May 2008, at 03:00, vicente.botet wrote:
> I find that subject should be non-preemptible threads.
Yes, I agree that is probably a better description.
> I think that your
> library in its own is a very good candidate to Boost.
That's nice to hear. Perhaps I will see if anybody else is interested
on the boost development list as you suggest.
>
>> A while back I put together a library[1] with the same interface as
>> Boost.Thread that I use for testing purposes, as it's nice to be able
>> to test algorithmic logic in isolation from synchronization logic.
>>
>> The implementation is cooperative, rather than preemptive, written in
>> terms of Fibers on Windows and the <ucontext.h> functionality on
>> POSIX
>> systems.
>>
>> Would this cooperative version of Boost.Thread be useful for boosters
>> in general? Regardless, someone here may find it useful!
>
>
> I have not taken a deep look yet, but I suspect a variation of the
> fiber
> conext can be used to implement deterministic alternation.
Yes. I have thought briefly about allowing a user-defined context-
switching strategy. Though it is currently deterministic, anyway. I
haven't written the rules down in much detail, but the basic idea is
that switches occur cyclically around all the active threads.
> I'm wondering if using a variation of the fiber conext can be used to
> implement deterministic alternation.
> and writing something like:
>
> class TrafficLight : public alternating_component {
> color::type state_;
> public:
> TrafficLight() : state_(color::red) {}
> void body() {
> for(;;) {
> state_ = color::red;
> yield();
> state_ = color::green;
> yield();
> }
> }
> };
> class Controller {
> TrafficLight& north_, south_;
> public:
> Controller(TrafficLight& north, TrafficLight& south) :
> void operator() () {
> north_(); // north.state_==red
> south_();
> south_(); // south.state_==green
> for(;;) {
> // wait some time
> sleep(2);
> // switch the states
> south_();
> north_();
> }
> }
> };
>
> What do you think?
The only thing to be careful of here is that the current
implementation of coco::sleep() will perform a context switch if it
needs to wait, so the sleep(2) in your code should be a real sleep.
Otherwise, this kind of coroutine-esque code should be perfectly
possible.
Actually this is a problem with coco::thread::sleep(): if all threads
sleep at the same time, it effectively does a glorified busy loop. At
some point I aim to detect this situation and do a real sleep.
coco::thread also has a public-though-undocumented schedule()
function, which could be used to switch to a specific thread, rather
than leaving it up to yield to choose.
> A non-premptible thread will be a particular case of
> alternating_component
> scheduled by a specific scheduler.
> Do you have some performances messures?
I'm afraid not, as it wasn't built with speed in mind. Which aspect of
performance are you interested in? I'm guessing the speed of context
switches?
> It is a pity that xcontext.h is obsolete and that this header file is
> missing from gnulib on some platforms as OpenBSD 3.8, Cygwin, mingw,
> BeOS.
On MinGW I'm actually using the Windows Fibers stuff. I don't know if
this is possible on cygwin. I suspect not, though I haven't looked. I
found that certain exception handling mechanisms are incompatible with
Fibers[1].
Indeed it's a pity that POSIX has deprecated the user-space threads
stuff, at least as far as this project is concerned. On the other
hand, I don't think they'll disappear anytime soon. Indeed, they have
only recently appeared on Mac OS X.
I'm not sure if I'll be able to use longjmp and friends instead, but
it's something I can look in to. It would be nice to support other
systems.
> The Boost.Coroutine library use also xcontext.h .
I actually looked at using Boost.Coroutine for the implementation, but
I concluded that it wasn't suitable for some reason I can't quite
recall. Something about giving the current thread an identifier,
maybe... I might look at this again at some point, too.
Kind regards,
Edd
[1] http://thread.gmane.org/gmane.comp.gnu.mingw.user/25631