Say I have two futures, future<int> a and future<char> b. Is there any way to put both of these (or pointers to them) into any of the standard containers (std::{list,vector,...}?
The problem I intend to solve with this:
Setup: I have a thread pool library that allows the user to submit tasks in the form of arbitrary functions w/ arguments as tasks. The pool executes the function w/ args in a worker thread and the result is communicated to the user by a future<func::result_type>, where func is an std::function<?>. (? Being a wildcard, b/c it words with any function.) These futures are also the only external way to wait on a task to complete. If one only wants to wait until they execute, one must call future::get() and ignore the result.
Problem: I want to provide a way to wait on all the tasks currently in the queue. To do this, I need to keep a list of all the futures so I can call get on them.
The library I'm talking about, in case you really need context (280 loc): https://github.com/Tyler-Hardin/thread_pool
I don't quite understand why you would need this, but you can use a standard technique - template wrappers with common base class:
class FutureHolderBase {
public:
virtual ~FutureHolderBase() = default;
};
template<typename T>
class FutureHolder : public FutureHolderBase {
private:
std::future<T> m_future;
};
int main() {
// unfortunately can't use list-initialization here because it supports only copyable types
std::vector<std::unique_ptr<FutureHolderBase>> v;
v.push_back(std::make_unique<FutureHolder<int>>());
v.push_back(std::make_unique<FutureHolder<float>>());
}
Related
I am building a system where a top layer communicates with a driver layer, who in turn communicate with a I2C layer. I have put my I2C driver behind a message queue, in order to make it thread safe and serialize access to the I2C bus.
In order to return the reply to the driver, the I2C layer returns a std::future with a byte buffer inside that is filled out when the I2C bus read actually happens.
All this works and I like it.
My problem is that I also want the driver to return a future to the top layer, however this future will then depend on the previous future (when the I2C driver future-returns a byte buffer, the driver will have to interpret and condition those bytes to get the higher-level answer), and I am having problems making this dependency "nice".
For example, I have a driver for a PCT2075 temperature sensor chip, and I would like to have a:
future<double> getTemperature()
method in that driver, but so far I can't think of a better way than to make an intermediate "future-holder" class and then return that:
class PCT2075
{
public:
class TemperatureFuture
{
private:
std::future<std::pair<std::vector<uint8_t>, bool>> temperatureData;
public:
TemperatureFuture(std::future<std::pair<std::vector<uint8_t>, bool>> f);
template< class Clock, class Duration >
std::future_status wait_until(const std::chrono::time_point<Clock, Duration>& timeout_time) const;
void wait() const; // wait and wait_until just waits on the internal future
double get();
};
TemperatureFuture getTemperature();
};
This structure works and I can go forward with it, but for some reason I am not super happy with it (though I can't quite explain why... :/ ).
So my questions are:
Is there some pattern that can make this better?
Would it make sense to let TemperatureFuture inherit directly from std::future (I have heard that "do not inherit from std classes" is a good rule)?
Or is this just how you do it, and I should stop worrying about nothing?
Ps. I also have another method whose answer relies on two I2C reads, and thus two different futures. It is possible to rework this to only have a one-on-one dependency, but the current way can handle the one-on-multiple variant so it would be nice if a potential new proposal also could.
You are looking for an operation called then, which as commenters note is sadly missing even in C++20.
However, it's not hard to write a then yourself.
template<typename Fun, typename... Ins>
std::invoke_result_t<Fun, Ins...> invoke_future(Fun fun, std::future<Ins>... futs) {
return fun(futs.get()...);
}
template<typename Fun, typename... Ins>
std::future<std::invoke_result_t<Fun, Ins...>> then(Fun&& fun, std::future<Ins>... futs) {
return std::async(std::launch::deferred, invoke_future<Fun, Ins...>, std::forward<Fun>(fun), std::move(futs)...);
}
I expect something like this wasn't standardised because it makes loads of assumptions about how the function should be run once the result is ready.
A future that just reinterprets the results of a previous future or gathers multiple futures is a good job for std::async(std::launch::deferred, ...). This doesn't launch any thread, it executes on request.
std::future<int> f1 = std::async([]() -> int { return 1; });
std::future<float> f2 = std::async(
std::launch::deferred,
[](std::future<int>&& f) -> float { return f.get(); },
std::move(f1));
std::printf("%f\n", f2.get());
The downside is that certain features will not work, e.g. wait_until.
If, instead, you need to launch a new asynchronous action once the first future is ready (e.g. send another I2C message, or compute the higher-level result in a thread pool), C++ does not offer any better solution than making this part of your original task. For example your I2C driver could accept a list of std::functions as callbacks.
I often find myself trying to decouple objects using the boost/QT signals. The naive way to do this is for each concrete type I want to communicate, I create a new signal and slot signature and wire up all the dependent objects. This leads to the visitor pattern, ideally I'd like to emit a visitor and have all the listening classes receive the visitor and perform an action. The interfaces would look like this:
class IVisitor
{
public:
Visit(IListener* Listener);
Visit(ConcreteListener1* Listener);
Visit(ConcreteListener2* Listener);
//And so on from here
};
Likewise if I want multiple commands I need to make multiple visitors:
class IListener
{
public:
Visit(IVisitor* Listener);
Visit(ConcreteVisitor1* Listener);
Visit(ConcreteVisitor2* Listener);
//And so on from here
};
To me this seems to violate the open/closed principle because I'm always having to go back an update my interfaces each time I want to connect a new listener or implement a new visitor. Ideally, this would use double dispatch and be able to leave the base classes intact with only the derived classes changing based on the visitors they accept using the base class interface if no specialized interface is present. I know this is not possible in C++ because function overloads and argument types are based on compile time information.
In general this is all about re-implementing multiple dispatch in a program that doesn't support it.
I have seen many debates about the visitor pattern and it seems like the pattern that people use and hate. It seems its visitor pattern or dynamic_cast? I have implemented a templated helper class that automates the dreaded if-else logic when using dynamic_cast for better maintenance. So my question is this... Are the pitfalls of using dynamic_cast worse than the pitfalls mentioned for the visitor pattern when maintenance of logic largely automated?
EDIT:
std::visit does indeed seem to be a great way to solve this issue of multiple dispatch. I was able to create a simple messaging system using the following one liner:
std::visit(overloaded{ [&](auto arg) {Listener->Recieve(arg); } }, pCommand->AsVariant());
With visitor pattern,
when a new listener is added to the IVisitor, you have the guaranty that existing visitors have to handle that new listener.
With simple dynamic_cast, not handled listeners is more probable.
depending how (each, (so no uniform behavior)) classes implement it, you might throw for unsupported listener, or fallback to "default implementation" (as do nothing).
Alternative to dynamic_cast is std::variant usage which, as for visitor, requires to know all listeners types.
std::variant has a std::visit which can even do multiple dispatch :-)
so, something like:
using ListenerVariant = std::variant<ConcreteListener1*, ConcreteListener2* /*..*/>;
class IListener
{
public:
virtual ListenerVariant AsVariant() = 0;
// ...
};
and then
std::visit(overloaded{[](ConcreteListener1* l){/*..*/},
[](ConcreteListener2* l){/*..*/}},
listener.AsVariant());
You have the guaranty that all cases are handled, (you can even have fallback).
I am using a small embedded RTOS which supports threads. I am programming in C++ and want to create a class that will allow me to run an arbitrary member function of any class as a thread. The RTOS does not directly support creating threads from member functions but they work fine if called from withing a thread. Boost::thread is not available on my platform.
I am currently starting threads in an ad-hoc fashion through a friend thread_starter() function but it seems that I must have a seperate one of these for each class I want to run threads from. My current solution of a thread base class uses a virtual run() function but this has the disadvantage that I can only start 1 thread for a class and that is restricted to the run() function + whatever that calls in turn (ie I cannot run an arbitrary function from within run() elegantly)
I would ideally like a class "thread" that was templated so I could perform the following from within a class "X" member function :
class X
{
run_as_thread(void* p)';
};
X x;
void* p = NULL;
template<X>
thread t(x, X::run_as_thread, p);
//somehow causing the following to be run as a thread :
x->run_as_thread(p);
Sorry if this has been done to death here before but I can only seem to find references to using Boost::thread to accomplish this and that is not available to me. I also do not have access to a heap so all globals have to be static.
Many thanks,
Mike
If your compiler is modern enough to support the C++11 threading functionality then you can use that.
Maybe something like this:
class X
{
public:
void run(void *p);
};
X myX;
void *p = nullptr;
std::thread myThread(std::bind(&X::run, myX, p));
Now X::run will be run as a thread. Call std::thread::join when the thread is done to clean up after it.
Assuming your RTOS works a bit like pthreads, and you don't have C++11 (which probably makes assumptions about your threading support) you can use this sort of mechanism, but you need a static method in the class which takes a pointer to an instance of the class. Thus (roughly)
class Wibble
{
public:
static void *run_pthread(void *me)
{
Wibble *x(static_cast<Wibble *>(me));
return x->run_thread_code();
}
private:
void *run_thread();
};
Wibble w;
pthread_create(&thread, &attr, Wibble::run_pthread, &w);
Passing arguments is left as an exercise to the reader...
This can be templatised with a bit of effort, but it's how the guts is going to need to work.
Have a look at my post on passing C++ callbacks between unrelated classes in non-boost project here.
It sounds like what you are asking is a way to run an arbitrary member function on a class asynchronously. I take it from your comment about the virtual run() function:
"this has the disadvantage that I can only start 1 thread for a class"
...to mean that you do not like that option because it causes all function calls to execute in that thread, when what you want is the ability to have individual function calls threaded off, NOT just create an object-oriented thread abstraction.
You should look into a thread pooling library for your target platform. I can't offer any concrete suggestions given no knowledge of your actual platform or requirements, but that should give you a term to search on and hopefully get some fruitful results.
I have a number of algorithms for community detection on graphs that I want to now visualise them. This visualisation requires me to 'hijack' these algorithms while they execute and log what they are doing. Specifically this will mean passing a reference to a std::vector<graph_partition> as an argument to these algorithms, and appending to that vector as the algorithm proceeds.
Therefore to each algorithm (which are typically just functions), I would need to add a further argument for the &std::vector<graph_partition>, and one or two lines of code for the logging.
I will not always want/need to log however, and so doing this in an intelligent way has proved non-trivial. I have thought of:
Write separate logging versions of each algorithm: The problem here is that I'll be repeating myself massively, since 95% of the logging and non-logging functions will be the same. You could say my code should be so modular that no repetition should occur, but in practice unless I have lots of tiny trivial functions I would have to repeat myself.
Have single function with a conditional argument to decide whether to log or not: Problem is what do I pass for &std::vector<graph_partition> when I don't want to use it? Also (probably minuscule) runtime hit of continuously evaluating conditional.
Some macro wizardry: Macros are a bit evil and would prefer to avoid them if possible.
Just log by default, discard if I don't need it: Convenient but wasteful, both in terms of runtime and space.
Any ideas or thoughts on these would be appreciated.
If you fancy using templates, I don't think you really need variadic templates. If you're happy to recompile in order to switch logging on and off:
struct NoLogging {
void log(const graph_partition &) {}
};
struct Logging {
std::vector<graph_partition> vec;
void log(const graph_partition &p) {
vec.push_back(p);
}
};
template <typename Logger>
void some_algorithm(Logger &logger) {
// do some stuff
logger.log(something);
}
// optionally, for convenience
void some_algorithm() {
NoLogging l;
some_algorithm(l);
}
// user writes:
some_algorithm();
// or
Logging l;
some_algorithm(l);
// do something with l.vec
The difference between this and "just log by default, even if I don't need it", is that an even vaguely decent compiler will completely remove the calls to log in some_algorithm<NoLogging>, because it can see that they do nothing.
If you don't want to have to recompile, you could have a runtime switch between the two different sets of instantiations - it may or may not be convenient to do this via some polymorphic interface that provides all the algorithms and has two derived classes, from a template like so:
template <typename Logger>
struct ConcreteAlgorithms : public Algorithms {
Logger logger;
static void some_algorithm() {
::some_algorithm(logger);
}
// more algorithms
};
Algorithms *get_algorithms(bool with_logging) {
if (with_logging) {
return new ConcreteAlgorithms<Logging>;
} else {
return new ConcreteAlgorithms<NoLogging>;
}
}
However, at this point you're going to have the code bloat of two different versions of the algorithms, so you might prefer to make the logger polymorphic and take the (probably tiny) runtime overhead instead, as per Mark's answer.
Pass a pointer to a parent logging class to each function. Have a child of the logging class that implements the logging function as a do-nothing, and use that one when you don't need logging. The real logging class would also be a child, and would contain the vector or a reference to it.
I'm looking for a solution for this problem in C or C++.
edit: To clarify. This is on a linux system. Linux-specific solutions are absolutely fine. Cross-plaform is not a concern.
I have a service that runs in its own thread. This service is a class with several methods, some of which need to run in the own service's thread rather than in the caller's thread.
Currently I'm using wrapper methods that create a structure with input and output parameters, insert the structure on a queue and either return (if a "command" is asynchronous) or wait for its execution (if a "command" is synchronous).
On the thread side, the service wakes, pops a structure from the queue, figures out what to execute and calls the appropriate method.
This implementation works but adding new methods is quite cumbersome: define wrapper, structure with parameters, and handler. I was wondering if there is a more straightforward means of coding this kind of model: a class method that executes on the class's own thread, instead of in the caller's thread.
edit - kind of conclusion:
It seems that there's no de facto way to implement what I asked that doesn't involve extra coding effort.
I'll stick with what I came up with, it ensures type safeness, minimizes locking, allows sync and async calls and the overhead it fairly modest.
On the other hand it requires a bit of extra coding and the dispatch mechanism may become bloated as the number of methods increases. Registering the dispatch methods on construction, or having the wrappers do that work seem to solve the issue, remove a bit of overhead and also remove some code.
My standard reference for this problem is here.
Implementing a Thread-Safe Queue using Condition Variables
As #John noted, this uses Boost.Thread.
I'd be careful about the synchronous case you described here. It's easy to get perf problems if the producer (the sending thread) waits for a result from the consumer (the service thread). What happens if you get 1000 async calls, filling up the queue with a backlog, followed by a sync call from each of your producer threads? Your system will 'play dead' until the queue backlog clears, freeing up those sync callers. Try to decouple them using async only, if you can.
There are several ways to achieve this, depending upon the complexity you want to accept. Complexity of the code is directly proportional to the flexibility desired. Here's a simple one (and quite well used):
Define a classes corresponding to each functionality your server exposes.
Each of these classes implements a function called execute and take a basic structure called input args and output args.
Inside the service register these methods classes at the time of initialization.
Once a request comes to the thread, it will have only two args, Input and Ouput, Which are the base classes for more specialized arguments, required by different method classes.
Then you write you service class as mere delegation which takes the incoming request and passes on to the respective method class based on ID or the name of the method (used during initial registration).
I hope it make sense, a very good example of this approach is in the XmlRpc++ (a c++ implementation of XmlRpc, you can get the source code from sourceforge).
To recap:
struct Input {
virtual ~Input () = 0;
};
struct Ouput {
virtual ~Output () = 0;
};
struct MethodInterface {
virtual int32_t execute (Input* __input, Output* __output) = 0;
};
// Write specialized method classes and taking specialized input, output classes
class MyService {
void registerMethod (std::string __method_name, MethodInterface* __method);
//external i/f
int32_t execute (std::string __method, Input* __input, Output* __output);
};
You will still be using the queue mechanism, but you won't need any wrappers.
IMHO, If you want to decouple method execution and thread context, you should use Active Object Pattern (AOP)
However, you need to use ACE Framework, which supports many OSes, e.g. Windows, Linux, VxWorks
You can find detailed information here
Also, AOP is a combination of Command, Proxy and Observer Patterns, if you know the details of them, you may implement your own AOP. Hope it helps
In addition to using Boost.Thread, I would look at boost::function and boost::bind. That said, it seems fair to have untyped (void) arguments passed to the target methods, and let those methods cast to the correct type (a typical idiom for languages like C#).
Hey now Rajivji, I think you have it upside-down. Complexity of code is inversely proportional to flexibility. The more complex your data structures and algorithms are, the more restrictions you are placing on acceptable inputs and behaviour.
To the OP: your description seems perfectly general and the only solution, although there are different encodings of it. The simplest may be to derive a class from:
struct Xqt { virtual void xqt(){} virtual ~Xqt(){} };
and then have a thread-safe queue of pointers to Xqt. The service thread then just pops the queue to px and calls px->xqt(), and then delete px. The most important derived class is this one:
struct Dxqt : Xqt {
xqt *delegate;
Dxqt(xqt *d) : delegate(d) {}
void xqt() { delegate->xqt(); }
};
because "all problems in Computer Science can be solved by one more level of indirection" and in particular this class doesn't delete the delegate. This is much better than using a flag, for example, to determine if the closure object should be deleted by the server thread.