Re: Non pre-emptible Boost.Thread

----- Original Message ----- 
From: "Edd Dawson" <lists <at> mr-edd.co.uk>
To: <boost <at> lists.boost.org>
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> mr-edd.co.uk>
>> To: <boost <at> lists.boost.org>
>> 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:
>>>>> Hello,
>>>>>
>>>>> A while ago, I implemented the Boost.Thread API in terms of Windows
>>>>> Fibers and <uncontext.h> functionality. The result is the ability
>>>>> to
>>>>> run code written with boost threads in a single OS thread.
>>>>>
>>>>> I find it useful for writing tests where determinism is important
>>>>> i.e.
>>>>> 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
>>>>> if
>>>>> it might be thought suitable for inclusion in the boost library
>>>>> collection.
>>>>>
>>>>
>>>> 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
>>>> (http://www.gnu.org/software/pth/)?
>>>
>>> No different. Except it would work on Windows, whereas a pth-based
>>> implementation of Boost.Thread wouldn't (AFAICT).
>>
>>
>> Hello,
>>
>> 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
>> you
>> 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
>> easier
>> 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
>> concurrency
>> 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
>> threads,
>> 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
>> suspend()
>> 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 
thread ready.

>> 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
>> the
>> 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-
>> preemptible
>> 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.

Great

>> 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
>> user-space
>> context switch?
>
> This would be the ideal situation.
>
> Giovanni mentioned his context refactoring, which I will also look in
> to.
>
> Kind regards,
>
> Edd

Good look

Vicente 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost