Re: [boost] [threadpool] new version v12

Subject: Re: [boost] [threadpool] new version v12
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-11-03 06:17:56

----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, November 03, 2008 10:25 AM
Subject: Re: [boost] [threadpool] new version v12

> "vicente.botet" <vicente.botet_at_[hidden]> writes:
>
>> From: "Anthony Williams" <anthony.ajw_at_[hidden]>
>>
>>
>> For task the same applies; there are some entities(functions, classes,
>> ..) that are task-safe and others that need some task specific
>> synchronization tools to ensure task safety.
>
> Yes. Unfortunately in some cases the set of functions that are not
> "task safe" includes particular uses of the standard C library and use
> of particular C++ constructs in particular ways on some platforms.

> You need to be aware that these things will be replaced if the task is
> suspended and a new fiber scheduled.

Yes as this is already the case for TSS, we need to recover the TSS data on 
the stack before calling other functions that could modify it. We need to 
take care of this.

> Doubly so if the task is migrated to another physical thread.

I don't think we need to migrate an already started task.

>This makes it a really bad idea to wait
> for a future in a catch block, for example.

Sorry I don't see why. Could you describe the issue?

>> I think the fork/join framework work well for task-safe entities while
>> will have unexpected behavior otherwise.
>> * The first question is whether we can use such a framework knowing
>> that we need to take care of the task safety or discard it because it
>> is dangerous when the entities are not task-safe.
>
> Of course we can. However, we need to be sure to publicise this fact.

Of course.

>> * The second question if we use this kind of framework is how can we
>> make task-unsafe entities task-safe using some kind of synchronization
>> or specific context at the task level.
>
> In the general case, I don't think we can. However, we can do things
> to mitigate the problem. For example if the thread pool collaborated
> with boost::thread, it could switch the thread data so you had a
> different thread::id value, and thread_specific_ptr values were local
> to the task.

Yes this could be a possibility. The other been stating that thread::id and 
thread-specific data must be used carefully on the context of task 
scheduling, as global data is not thread-safe.

> This doesn't help with locks or thread-specific data
> taken from outside of boost (e.g. in the CRT), but it does help
> somewhat.

Are you saying that if we switch the thread data locks will work when we use 
boost::thread? I though that mutex are associated to the underlying OS 
thread.

> Also, it might be useful to have a "don't nest tasks" flag, like
> boost::disable_interruption:
>
> void foo()
> {
>    boost::tp::disable_task_nesting dtn;
>    some_future.get();    // won't schedule another task on this thread
> }   // task nesting enable again
>

Yes, I was thinking also on this kind of construction to enable/disable task 
stealing. This could enable to have a single implementation for the 
thread_pool. This kind of scoped construction will be used to change how the 
thread_pool schedules tasks.

Vicente