Boost logo

Boost :

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

Kind regards,


Boost list run by bdawes at, gregod at, cpdaniel at, john at