BOOST Library
tom
i am trying to implement the set/get functionality (known from posix
threads) by using the BOOST library.
Can any one help me?
Are thre any examples in the web?
Regards
tom
Torsten Robitzki
> i am trying to implement the set/get functionality (known from posix
> threads) by using the BOOST library.
what is the "set/get functionality"? I know posix and boost, but never
heard this term.
regards
Torsten
--
kostenlose Wirtschaftssimulation: http://www.financial-rumors.de
Vaclav Haisman
> Hello,
>
> i am trying to implement the set/get functionality (known from posix
> threads) by using the BOOST library.
>
> Can any one help me?
Do you mean the thread_specific_ptr class?
>
> Are thre any examples in the web?
That depends on what you really want. Try to explain it a bit more.
--
VH
tom
okay, i will explain.
I have to migrate a source which uses a specific thread library
(ospace class library). This library manages the tread local storage
in the same way, pthreads do.
You have to store in memorry, by giving a key (like pthread_set) .With
this key you can the memory.
I do not know how can i this do with boost. Boost uses
thread_specific_ptr, that seems to be a different way of managing tls.
Greets
Thomas
Anthony Williams
boost::thread_specific_ptr allows you to store a separate value on each
thread. The boost::thread_specific_ptr instance itself is the key.
Just like pthread_set/getspecific, thread_specific_ptr stores a
pointer. The difference is that it is a typed pointer (e.g. int* or
std::string* or my_class*), and that by default the pointed-to object is
destroyed (by invoking "delete p" for the pointer p) when the thread
exits. Just like with pthreads, you can specify an alternate cleanup
function when you create your thread_specific_ptr instance.
Anthony
--
Author of C++ Concurrency in Action | http://www.manning.com/williams
just::thread C++0x thread library | http://www.stdthread.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK
rani_s...@hotmail.com
> Just like pthread_set/getspecific, thread_specific_ptr stores a
> pointer. The difference is that it is a typed pointer (e.g. int* or
> std::string* or my_class*), and that by default the pointed-to object is
> destroyed (by invoking "delete p" for the pointer p) when the thread
> exits.
On Windows, when do you call the thread exit cleanup?
Do you use DLL_THREAD_DETACH or worker thread that listen on the
thread handle?
Thanks,
Rani
Anthony Williams
If the boost lib is built as a separate DLL then it uses
DLL_THREAD_DETACH. If it is built as a static lib then it uses the win32
PE TLS callbacks to trap DLL_THREAD_DETACH.
Anthony
--
Author of C++ Concurrency in Action | http://www.manning.com/williams
just::thread C++0x thread library | http://www.stdthread.co.uk
Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
rani_s...@hotmail.com
> rani_shar...@hotmail.com writes:
> > On Windows, when do you call the thread exit cleanup?
> > Do you use DLL_THREAD_DETACH or worker thread that listen on the
> > thread handle?
>
> If the boost lib is built as a separate DLL then it uses
> DLL_THREAD_DETACH. If it is built as a static lib then it uses the win32
> PE TLS callbacks to trap DLL_THREAD_DETACH.
This will not work, for DLL, if DisableThreadLibraryCalls was called.
Do you require avoiding this in the docs?
There is also the infamous limitation of DllMain notifications:
Because DLL notifications are serialized, entry-point functions should
not attempt to communicate with other threads or processes. Deadlocks
may occur as a result.
</MSDN>
It should be rare for TLS item to sync with another thread but it's
quite hard to formulate a requirement against it (e.g. maybe it calls
some API that tries doing so).
In my modest TLS implementation I use RegisterWaitForSingle (w/ thread
handle) to get a thread-exit notification and therefore I avoid the
DllMain thread notifications and also notifications for irrelevant
threads not using TLS (tough register-wait is heavyweight compared
with DLL/TLS notifications).
Rani
Anthony Williams
> On Feb 4, 1:42 am, Anthony Williams <anthony....@gmail.com> wrote:
>> rani_shar...@hotmail.com writes:
>> > On Windows, when do you call the thread exit cleanup?
>> > Do you use DLL_THREAD_DETACH or worker thread that listen on the
>> > thread handle?
>>
>> If the boost lib is built as a separate DLL then it uses
>> DLL_THREAD_DETACH. If it is built as a static lib then it uses the win32
>> PE TLS callbacks to trap DLL_THREAD_DETACH.
>
> This will not work, for DLL, if DisableThreadLibraryCalls was called.
> Do you require avoiding this in the docs?
If someone explicitly calls that function for the boost thread DLL, they
asked for the consequences.
Also, from MSDN: "The DisableThreadLibraryCalls function fails if the DLL
specified by hModule has active static thread local storage,"
I haven't tested to see whether the use TLS by Boost.Thread counts as
"active static thread local storage" or not.
Also from MSDN: "Do not call this function from a DLL that is linked to
the static C run-time library (CRT). The static CRT requires
DLL_THREAD_ATTACH and DLL_THREAD_DETATCH notifications to function
properly."
It's probably wise to advise against it in the docs though.
> There is also the infamous limitation of DllMain notifications:
> Because DLL notifications are serialized, entry-point functions should
> not attempt to communicate with other threads or processes. Deadlocks
> may occur as a result.
That is indeed a potential issue.
> In my modest TLS implementation I use RegisterWaitForSingle (w/ thread
> handle) to get a thread-exit notification and therefore I avoid the
> DllMain thread notifications and also notifications for irrelevant
> threads not using TLS (tough register-wait is heavyweight compared
> with DLL/TLS notifications).
That's a nice idea, with a different set of trade-offs.
If you do that then the TLS destructor is run from a different
thread. With the DLL_THREAD_DETACH notifications the destructor is run
from the exiting thread. This can have implications e.g. for use of
other thread-local variables, or calls to DestroyWindow (which have to
be done on the same thread that created the window) or similar.
rani_s...@hotmail.com
> rani_shar...@hotmail.com writes:
> > On Feb 4, 1:42 am, Anthony Williams <anthony....@gmail.com> wrote:
> >> rani_shar...@hotmail.com writes:
> >> > On Windows, when do you call the thread exit cleanup?
> >> > Do you use DLL_THREAD_DETACH or worker thread that listen on the
> >> > thread handle?
>
> >> If the boost lib is built as a separate DLL then it uses
> >> DLL_THREAD_DETACH. If it is built as a static lib then it uses the win32
> >> PE TLS callbacks to trap DLL_THREAD_DETACH.
>
> > This will not work, for DLL, if DisableThreadLibraryCalls was called.
> > Do you require avoiding this in the docs?
>
> If someone explicitly calls that function for the boost thread DLL, they
> asked for the consequences.
How can one tell that this should be avoided if it's not documented?
This is also quite intrusive since TLS might be implementation detail
(e.g. optimization) of some static library.
> Also, from MSDN: "The DisableThreadLibraryCalls function fails if the DLL
> specified by hModule has active static thread local storage,"
I forgot that - the error is ERROR_MOD_NOT_FOUND ;-)
There is still problem with the DLL_THREAD_DETACH case but you can
protect against DisableThreadLibraryCalls using TLS notifications.
> Also from MSDN: "Do not call this function from a DLL that is linked to
> the static C run-time library (CRT). The static CRT requires
> DLL_THREAD_ATTACH and DLL_THREAD_DETATCH notifications to function
> properly."
That's only true to the static CRT which is highly not recommended
(e.g. leaks when used in exe since TLS notifications are not used).
The dynamic CRT handles this internally for the favor of all.
Otherwise it's highly recommended to avoid thread notifications if
they are not used.
This is a common practice in windows components.
> > In my modest TLS implementation I use RegisterWaitForSingle (w/ thread
> > handle) to get a thread-exit notification and therefore I avoid the
> > DllMain thread notifications and also notifications for irrelevant
> > threads not using TLS (tough register-wait is heavyweight compared
> > with DLL/TLS notifications).
>
> That's a nice idea, with a different set of trade-offs.
>
> If you do that then the TLS destructor is run from a different
> thread. With the DLL_THREAD_DETACH notifications the destructor is run
> from the exiting thread. This can have implications e.g. for use of
> other thread-local variables, or calls to DestroyWindow (which have to
> be done on the same thread that created the window) or similar.
But the TLS might anyway be destructed upon key destroy...
I think that DestroyWindow from DllMain is not recommended.
Using it in TLS seems strange but that's debatable.
Thanks,
Rani
Anthony Williams
> On Feb 4, 12:50 pm, Anthony Williams <anthony....@gmail.com> wrote:
>> rani_shar...@hotmail.com writes:
>> > On Feb 4, 1:42 am, Anthony Williams <anthony....@gmail.com> wrote:
>> >> rani_shar...@hotmail.com writes:
>> >> > On Windows, when do you call the thread exit cleanup?
>> >> > Do you use DLL_THREAD_DETACH or worker thread that listen on the
>> >> > thread handle?
>>
>> >> If the boost lib is built as a separate DLL then it uses
>> >> DLL_THREAD_DETACH. If it is built as a static lib then it uses the win32
>> >> PE TLS callbacks to trap DLL_THREAD_DETACH.
>>
>> > This will not work, for DLL, if DisableThreadLibraryCalls was called.
>> > Do you require avoiding this in the docs?
>>
>> If someone explicitly calls that function for the boost thread DLL, they
>> asked for the consequences.
>
> How can one tell that this should be avoided if it's not documented?
Indeed. I did say it was probably worth adding to the docs.
>> > In my modest TLS implementation I use RegisterWaitForSingle (w/ thread
>> > handle) to get a thread-exit notification and therefore I avoid the
>> > DllMain thread notifications and also notifications for irrelevant
>> > threads not using TLS (tough register-wait is heavyweight compared
>> > with DLL/TLS notifications).
>>
>> That's a nice idea, with a different set of trade-offs.
>>
>> If you do that then the TLS destructor is run from a different
>> thread. With the DLL_THREAD_DETACH notifications the destructor is run
>> from the exiting thread. This can have implications e.g. for use of
>> other thread-local variables, or calls to DestroyWindow (which have to
>> be done on the same thread that created the window) or similar.
>
> But the TLS might anyway be destructed upon key destroy...
>
> I think that DestroyWindow from DllMain is not recommended.
> Using it in TLS seems strange but that's debatable.
It was just the first thing that occurred to me as something where the
thread it is called from matters.