Re: Non pre-emptible Boost.Thread

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

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?

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?

Do your library manages with errno?

If I have understood, all the non-preemtible threads are attached to the 
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-preemptible 
threads to this specific scheduler.

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? Edd, Giovanni, what do you think?

Best

Vicente 

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