On Thu, 8 Nov 2012, Kirk, Benjamin (JSC-EG311) wrote:
As of yesterday I've added support for the other multithreading use
case, asynchronous execution of an operation that would otherwise
block. This is commonly used in GUI programming but not needed as
frequently in scientific computing. Still, there are some use cases
where I've wanted it, and now it is available. The first such
occurrence is overlapping disk I/O with MPI communication.
Note that boost::thread is also a workable alternative here, and
I'll probably add support for it too along the lines of
'BEST_STD_THREAD'…
This sounds good (especially combined with some of the ideas I've been
hashing out with Vikram for transient problems' I/O), but I have
questions:
We can't standardize on std::thread without requiring C++11, but is
there any reason not to standardize on just one of tbb::thread or
boost::thread as the fallback? With "BEST_UNORDERED_MAP" there's
three different possible hash map implementations that users might
have available (C++11, TR1, GNU) and we'd generally prefer any of the
above over the always-available std::map fallback, so we need a lot of
options. But if we're including a chunk of Boost, can't we just use
boost::thread and be done with it?
With TBB style threading, the single-threaded fallback is simply "one
thread handles the entire range". What's the single-threaded fallback
for asynchronous threading? The thread's function doesn't actually
get started executing until the join() call?
If we start using MPI I/O (or PHDF5, etc), is this going to be a
conflict? We currently don't try to do any MPI communication from
within threads so we don't care about whether our MPI stacks are
thread-safe or not. That might have to change if we don't want to
foreclose the possibility of using an underlying parallel I/O library,
no?
---
Roy
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
