headers
Edd Dawson | 22 May 02:44

Non pre-emptible Boost.Thread

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.

More information is available here:
http://www.mr-edd.co.uk/?page_id=91

Direct link to source code:
http://www.mr-edd.co.uk/files/coco/coco-0.2.0.zip

Kind regards,

Edd
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Mathias Gaunard | 22 May 20:03

Re: Non pre-emptible Boost.Thread

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.

How is that different from boost.coroutine?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Edd Dawson | 22 May 20:49

Re: Non pre-emptible Boost.Thread


On 22 May 2008, at 20:03, Mathias Gaunard 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.
>
> How is that different from boost.coroutine?

The API is different.

The underlying mechanisms used very similar. Indeed, I looked at  
Boost.Coroutine as a basis for the library, but concluded that it  
would be very difficult to use it. I must admit that the reason  
escapes me currently and I am am happy to be proven wrong in this  
regard. I think it might have been something to do with not being able  
to represent the "main thread".

Regardless of what's going on underneath, I wanted to be able to run  
my Boost.Thread-ed code without worrying about synchronization, to  
check the algorithmic correctness. The Boost.Coroutine interface is  
nothing like Boost.Thread's.

Kind regards,

Edd
(Continue reading)

Permalink | Reply |
headers
Ioannis Papadopoulos | 26 May 08:13

Re: Non pre-emptible Boost.Thread

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.
> 
> More information is available here:
> http://www.mr-edd.co.uk/?page_id=91
> 
> Direct link to source code:
> http://www.mr-edd.co.uk/files/coco/coco-0.2.0.zip
> 
> Kind regards,
> 
> Edd

So what exactly is the status of the library? And how much different 
would it be from recompiling Boost.Thread with pth 
(http://www.gnu.org/software/pth/)?
(Continue reading)

Permalink | Reply |
headers
Edd Dawson | 27 May 20:06

Re: 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
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 29 May 09:52

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
(Continue reading)

Permalink | Reply |
headers
Giovanni Piero Deretta | 29 May 12:49

Re: Non pre-emptible Boost.Thread

On Thu, May 29, 2008 at 9:52 AM, vicente.botet <vicente.botet <at> wanadoo.fr> 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?
(Continue reading)

Permalink | Reply |
headers
Edd Dawson | 30 May 21:19

Re: Non pre-emptible Boost.Thread


On 29 May 2008, at 12:49, Giovanni Piero Deretta wrote:

> I hope so. I've refactored coroutine's context as a (one shot)
> continuation, which should be usable as a generalized non local
> control flow abstraction.
>
> BTW, I was thinking of adding a task based interface on top of
> continuations in addition of a coroutine interface. Of course Edd's
> library would also work as well.

So can may I infer that you think I should be able to implement my  
library on top of the guts of Boost.Coroutine, now?

The thing that troubled me before was how to implement a default- 
constructed thread (or the stuff in the this_thread namespace in the  
1.35 API).

Kind regards,

Edd
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Giovanni Piero Deretta | 30 May 21:46

Re: Non pre-emptible Boost.Thread

On Fri, May 30, 2008 at 9:19 PM, Edd Dawson <lists <at> mr-edd.co.uk> wrote:
>
> On 29 May 2008, at 12:49, Giovanni Piero Deretta wrote:
>
>> I hope so. I've refactored coroutine's context as a (one shot)
>> continuation, which should be usable as a generalized non local
>> control flow abstraction.
>>
>> BTW, I was thinking of adding a task based interface on top of
>> continuations in addition of a coroutine interface. Of course Edd's
>> library would also work as well.
>
> So can may I infer that you think I should be able to implement my
> library on top of the guts of Boost.Coroutine, now?
>

I certainly hope so. Look at the (one shot) continuation at
http://tinyurl.com/55vzjm [boost trac].
Note that:
 - I might remove the movable interface and give it sort-of-copy
semantics (but you better not activate more than one copy: i.e. all
copies logically refer to the same state and activating one
immediately invalidates all other copies).
 - I will add support for passing one void* argument the the activated
continuation.

> The thing that troubled me before was how to implement a default-
> constructed thread (or the stuff in the this_thread namespace in the
> 1.35 API).
>
(Continue reading)

Permalink | Reply |
headers
Edd Dawson | 30 May 22:10

Re: Non pre-emptible Boost.Thread


On 30 May 2008, at 21:46, Giovanni Piero Deretta wrote:

> On Fri, May 30, 2008 at 9:19 PM, Edd Dawson <lists <at> mr-edd.co.uk>  
> wrote:
>>
>> On 29 May 2008, at 12:49, Giovanni Piero Deretta wrote:
>>
>>> I hope so. I've refactored coroutine's context as a (one shot)
>>> continuation, which should be usable as a generalized non local
>>> control flow abstraction.
>>>
>>> BTW, I was thinking of adding a task based interface on top of
>>> continuations in addition of a coroutine interface. Of course Edd's
>>> library would also work as well.
>>
>> So can may I infer that you think I should be able to implement my
>> library on top of the guts of Boost.Coroutine, now?
>>
>
> I certainly hope so. Look at the (one shot) continuation at
> http://tinyurl.com/55vzjm [boost trac].
> Note that:
> - I might remove the movable interface and give it sort-of-copy
> semantics (but you better not activate more than one copy: i.e. all
> copies logically refer to the same state and activating one
> immediately invalidates all other copies).
> - I will add support for passing one void* argument the the activated
> continuation.
(Continue reading)

Permalink | Reply |
headers
Edd Dawson | 30 May 21:13

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
(Continue reading)

Permalink | Reply |
headers
vicente.botet | 31 May 19:18

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-
(Continue reading)

Permalink | Reply |
headers
Mathias Gaunard | 31 May 13:39

Re: Non pre-emptible Boost.Thread

Edd Dawson wrote:

> No different. Except it would work on Windows, whereas a pth-based  
> implementation of Boost.Thread wouldn't (AFAICT).

Pth means Portable threads.
The whole point of pth is that it is fully platform independent, since
it only uses setjmp/longjmp (of course it can use more efficient if
available)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |
headers
Edd Dawson | 31 May 18:39

Re: Non pre-emptible Boost.Thread


On 31 May 2008, at 13:39, Mathias Gaunard wrote:

> Pth means Portable threads.
> The whole point of pth is that it is fully platform independent, since
> it only uses setjmp/longjmp (of course it can use more efficient if
> available)

Ok. Are you suggesting that I implement my library in terms of Pth?

That might be a good idea, but I think I'd prefer to use the guts of  
Boost.Coroutine, which now seems possible.

Edd
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply |

Gmane