status of boost::signal multi-threading support
What is the state of the multi-threading support for boost::signals? Stephen
On Jan 2, 2005, at 9:43 PM, Stephen torri wrote:
What is the state of the multi-threading support for boost::signals?
Signals does not behave well in a multi-threaded environment. Unless someone else takes on the task, I don't expect it to be done for a long time. Doug
On Tue, 2005-01-04 at 13:16 -0500, Doug Gregor wrote:
On Jan 2, 2005, at 9:43 PM, Stephen torri wrote:
What is the state of the multi-threading support for boost::signals?
Signals does not behave well in a multi-threaded environment. Unless someone else takes on the task, I don't expect it to be done for a long time.
What are the symptoms of this behavior? I am curious because, I am wondering in my ignorance, what are the components of the boost::signal library and how they can be multi-thread capable. This ofcourse is answered by reviewing the code. Stephen
On Jan 4, 2005, at 1:25 PM, Stephen torri wrote:
On Tue, 2005-01-04 at 13:16 -0500, Doug Gregor wrote:
On Jan 2, 2005, at 9:43 PM, Stephen torri wrote:
What is the state of the multi-threading support for boost::signals?
Signals does not behave well in a multi-threaded environment. Unless someone else takes on the task, I don't expect it to be done for a long time.
What are the symptoms of this behavior?
If you're using a signal from two threads concurrently, you will most likely see random crashes and other bad behavior. Signals keep a lot of state, even when they are being invoked, so just about anything can trip it up.
I am curious because, I am wondering in my ignorance, what are the components of the boost::signal library and how they can be multi-thread capable. This ofcourse is answered by reviewing the code.
Ideally, a thread-safe Signals would allow you to invoke in several threads at one, disconnect signals in several threads concurrently, etc. Doug
On Tue, 2005-01-04 at 13:59 -0500, Doug Gregor wrote:
What are the symptoms of this behavior?
If you're using a signal from two threads concurrently, you will most likely see random crashes and other bad behavior. Signals keep a lot of state, even when they are being invoked, so just about anything can trip it up.
The first thing that came to mind about this was thread specific storage (TSS). Here is a design pattern that will do what I think we need. http://www.cs.wustl.edu/~schmidt/PDF/TSS-pattern.pdf
Ideally, a thread-safe Signals would allow you to invoke in several threads at one, disconnect signals in several threads concurrently, etc.
Ok. I get the high-level concept. Stephen
On Jan 4, 2005, at 2:09 PM, Stephen torri wrote:
On Tue, 2005-01-04 at 13:59 -0500, Doug Gregor wrote:
What are the symptoms of this behavior?
If you're using a signal from two threads concurrently, you will most likely see random crashes and other bad behavior. Signals keep a lot of state, even when they are being invoked, so just about anything can trip it up.
The first thing that came to mind about this was thread specific storage (TSS). Here is a design pattern that will do what I think we need. http://www.cs.wustl.edu/~schmidt/PDF/TSS-pattern.pdf
That solves part of the problem, but there's more too it. Eric Niebler wrote a few posts to the developer's list describing some locking mechanisms that could be used to make signals work in a multithreaded environment. Doug
On Tue, 2005-01-04 at 21:27 -0500, Douglas Gregor wrote:
If you're using a signal from two threads concurrently, you will most likely see random crashes and other bad behavior. Signals keep a lot of state, even when they are being invoked, so just about anything can trip it up.
The first thing that came to mind about this was thread specific storage (TSS). Here is a design pattern that will do what I think we need. http://www.cs.wustl.edu/~schmidt/PDF/TSS-pattern.pdf
That solves part of the problem, but there's more too it. Eric Niebler wrote a few posts to the developer's list describing some locking mechanisms that could be used to make signals work in a multithreaded environment.
Doug
Do you know how to get a hold of Eric? I would like to see if he has done any work on the locking mechanisms. Stephen
On Jan 10, 2005, at 9:04 AM, Stephen torri wrote:
On Tue, 2005-01-04 at 21:27 -0500, Douglas Gregor wrote:
If you're using a signal from two threads concurrently, you will most likely see random crashes and other bad behavior. Signals keep a lot of state, even when they are being invoked, so just about anything can trip it up.
The first thing that came to mind about this was thread specific storage (TSS). Here is a design pattern that will do what I think we need. http://www.cs.wustl.edu/~schmidt/PDF/TSS-pattern.pdf
That solves part of the problem, but there's more too it. Eric Niebler wrote a few posts to the developer's list describing some locking mechanisms that could be used to make signals work in a multithreaded environment.
Doug
Do you know how to get a hold of Eric? I would like to see if he has done any work on the locking mechanisms.
Well, he's on the Boost mailing lists (probably all of them). I don't know if he's working on any of this, but you can read his ideas in this thread: http://lists.boost.org/MailArchives/boost/msg63938.php Doug
Douglas Gregor wrote:
On Jan 10, 2005, at 9:04 AM, Stephen torri wrote:
On Tue, 2005-01-04 at 21:27 -0500, Douglas Gregor wrote:
If you're using a signal from two threads concurrently, you will most likely see random crashes and other bad behavior. Signals keep a lot of state, even when they are being invoked, so just about anything can trip it up.
The first thing that came to mind about this was thread specific storage (TSS). Here is a design pattern that will do what I think we need. http://www.cs.wustl.edu/~schmidt/PDF/TSS-pattern.pdf
That solves part of the problem, but there's more too it. Eric Niebler wrote a few posts to the developer's list describing some locking mechanisms that could be used to make signals work in a multithreaded environment.
Doug
Do you know how to get a hold of Eric? I would like to see if he has done any work on the locking mechanisms.
I'm right over here. :)
Well, he's on the Boost mailing lists (probably all of them). I don't know if he's working on any of this, but you can read his ideas in this thread:
I haven't looked into this any further, sorry. -- Eric Niebler Boost Consulting www.boost-consulting.com
participants (4)
-
Doug Gregor -
Douglas Gregor
-
Eric Niebler -
Stephen torri