Re: 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?

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

> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost