From: Edd Dawson (lists_at_[hidden])
Date: 2008-05-30 15:13:06
On 29 May 2008, at 09:52, vicente.botet wrote:
> ----- Original Message -----
> From: "Edd Dawson" <lists_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Tuesday, May 27, 2008 8:06 PM
> Subject: Re: [boost] Non pre-emptible Boost.Thread
>> On 26 May 2008, at 08:13, Ioannis Papadopoulos wrote:
>>> Edd Dawson wrote:
>>>> A while ago, I implemented the Boost.Thread API in terms of Windows
>>>> Fibers and <uncontext.h> functionality. The result is the ability
>>>> run code written with boost threads in a single OS thread.
>>>> I find it useful for writing tests where determinism is important
>>>> to test algorithmic correctness in isolation from synchronization-
>>>> related concerns.
>>>> I haven't updated it to mirror the new 1.35 API yet, but I was
>>>> wondering if any other boost users would be interested in this or
>>>> it might be thought suitable for inclusion in the boost library
>>> So what exactly is the status of the library?
>> It compiles and works on the systems listed on my webpage. I can
>> replace all my code that uses boost threads very easily (i.e. by
>> changing compiler/linker include and library search directories). The
>> API still mirrors version 1.34 of Boost.Thread, however.
>>> And how much different
>>> would it be from recompiling Boost.Thread with pth
>> No different. Except it would work on Windows, whereas a pth-based
>> implementation of Boost.Thread wouldn't (AFAICT).
> The fact that your library mimics the Boost.Thread (1.34) interface
> is a
> good thing. Do you plan to move to the 1.35 interface? If yes, will
> allow thread interruption?
I do plan to move/fork to the 1.35 interface. I don't see why it
shouldn't support interruption in the same way as the preemptive
implementation, though I haven't looked closely at the details.
> I think however that limiting the utility of your library to making
> the writing of tests where determinism is important is not enough.
> Non-preemptible threads have its application domain on its own.
> * non preemtible threads could increases the responsiveness and
> of an event-driven application because no time slicing.
> * the critical sections needing some kind of synchronization are rare
I agree that non-preemptible threads have more uses than those
outlined in my motivating case, but I for one might prefer to use
something more akin to Boost.Coroutine. I can imagine that some might
prefer a threads API, though.
> Can an application needing only non-preemptible threads, perform
> better with
> your library than its preemptive Boost.Thread counterpart?
> Can an application needing only non-preemptible and preemptible
> perform better if we use your library for the non-preemptible
> threads and
> Boost.Thread for the others?
I think Giovanni answered these questions well.
> There are two functions that I would like to see in your library
> and resume(). Do you think that this represent a big development?
They're theoretically possible to implement, but this is heading more
towards what I would consider a coroutines-like interface.
There's already a semi-hidden function to schedule a specific thread.
I assume this would be what you have in mind for resume()? How would
you like suspend() to work? It sounds a bit like what some might call
a "yield"? Or perhaps it hides a thread from the scheduler?
> Do your library manages with errno?
I don't do anything special with errno. It may get set by the
underlying APIs that are used in the implementation. errno won't be
"thread" specific, I suspect, so as Giovanni said, make sure to read
from errno before a context switch.
> If I have understood, all the non-preemtible threads are attached to
> same scheduler, there is only one static scheduler.
> I was wondering if it
> will be possible to make the scheduler a thread specific storage of a
> preemptible Boost.Thread and attach the construction of non-
> threads to this specific scheduler.
It's possible. I will need to think hard about how to do it without
making things extremely messy :)
If I can leverage an existing scheduling mechanism, that would be
nice. I will look in to Asio's io_service.
> Do you think that we can have a common user space context which can
> be used
> by your library and the Boost/Coroutine library, and why not by
> other boost
> libraries or the users themself for implementing their own simple
> context switch?
This would be the ideal situation.
Giovanni mentioned his context refactoring, which I will also look in
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk