Boost logo

Boost :

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-05-29 03:52:32

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


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?



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