From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-31 13:18:05
----- Original Message -----
From: "Edd Dawson" <lists_at_[hidden]>
Sent: Friday, May 30, 2008 9:13 PM
Subject: Re: [boost] Non pre-emptible Boost.Thread
> 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?
The difference between yield and suspend is that yield yields the thread
imnmediately in the ready queue and suspends needs a resume to make the
>> 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.
This limits a little bit your goal to use instead of the Boost.Thread
library for test purposes.
>> If I have understood, all the non-preemtible threads are attached to
>> same scheduler, there is only one static scheduler.
> That's correct.
>> 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
> Kind regards,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk