I have an existing C/C++ application that communicates with other applications/systems through several interfaces (TCP, DB, shared memory). I would like to run the application once with the real environment and "record" all function calls and their return values (or changes to the buffers passed as parameters). I would record only the calls related with external interfaces (TCP, DB) with a "spy". Then I could run the application again but using "fake" functions that should return the previous recorded values. This way I could "replay" an execution, and check if the results match the original execution.
One important feature is to mock the time functions as well (sleep, time, GetLocalTime), because (for example) the calls to the DB may have the current date or time in the selects. It would be even better to be able to "replay" all the calls faster than the original execution (one day of execution could be replayed in a few minutes). For example a call to sleep(1000) should return without waiting, but successive calls to GetLocalTime should return 1 second more. This should take into account that other threads should have consistent values for the time (for example the library should allow 1 call to sleep(1000) for one thread and 10 calls to sleep(100) in another thread).
Ideally it shouldn't require a lot of changes or refactoring to the application, just redefining the calls to time functions as well as the calls to the libraries of the external interfaces (DB, TCP).
I would like to know if there exists some library or framework that implements these features or what could be a good starting point.
I have implemented several times solutions for similar problems, but for very simple modules, for example mocking a TCP connection to test a protocol implementation, but I feel like reinventing the wheel each time, and these simple solutions wouldn't scale well with more threads or interactions with more interfaces.
Since you mention that your application is C/C++, I will assume you have the ability to use C frameworks. I will talk about CMock and Unity in this answer. If object oriented principles are more prevalent in your task, then you can take a look at googlemock which is similar to CMock, but developed for C++ and accounts for classes.
--
CMock in combination with Unity may provide a framework for your testing needs.
CMock provides you the ability to easily mock public interfaces. For example, if you had the following trivial code to test:
void sendPacket(char * packet, int packetLen, int tcpSocket)
{
if (packet)
{
send(tcpSocket, packet, packetLen, 0);
}
}
You could use CMock to create a mock of the send call. This would allow you to verify the parameters passed to send, and thus verify content in buffers. You would also be able to verify the size returned by send. CMock's ExpectAndReturn variant of the mocked send function would allow you to perform these two verifications.
CMock also allows you to provide callbacks for mocked functions through the StubWithCallback variant. StubWithCallback will allow you to manually verify each call, in addition to doing special checks. You would be able to utilize StubWithCallback to record number of times a function is called, or almost anything else you can imagine. You would also be able to use the StubWithCallback for your needs with time, sleep, etc. You can mock individual calls with different stub callbacks-- some threads will start with a stub sleep callback that immediately returns, while threads you specify for testing can use a stub sleep callback that performs the full sleep.
You can find more information on CMock here: http://throwtheswitch.org/white-papers/cmock-intro.html
Related
My general idea is that a single-threaded application ( the Lua interpreter ) will always deteriorate the performance of a multi-threaded application that depends on it ( a generic C++ application ).
To circumvent this problem I'm thinking about an asynchronous approach on the interpreter while keeping the C++ application multi-threaded, this basically means that based on my approach a Lua interpreter should somehow push the entire script/file in a scheduler with an asynchronous approach ( without waiting for the result ) and it's up to the well designed C++ multi-threaded messaging system to keep everything sequential.
The usual relationship is C/C++ function <-> Lua ( with a sequential approach ) ; I would like to have something like C++ messaging system <-> entire Lua script .
I'm also open to any kind of approach that can solve this and really help the mix between Lua and a C++ application designed for multi-threading.
Is this approach made possible by some piece of software ?
EDIT
I need something "user-proof" and I need to implement this behaviour right in C++/Lua API design.
One option is to implement communication to lua as a co-routine. Messages are sent to C++ via coroutine.yield(messagedata), and then it sends back results via lua_resume. (See also: lua_newthread). You could even wrap your functions to provide a nicer event UI.
function doThing(thing, other, data)
return coroutine.yield("doThing", thing, other, data)
end
You can still only have one thread running the lua interpreter at any given time (you will have to do locking) but you can have multiple such co-routines running concurrently.
Concurrency in Lua is a topic that has many many solutions. Here is a resource:
http://lua-users.org/wiki/MultiTasking
You actually can make it easy for yourself since you do not actually have to run Lua itself multithreaded, which would impose a number of additional issues.
The obvious solution is running Lua in a separate thread but providing only a thin API for Lua in which every single API call immediately either forks a new thread/process or uses some sort of message passing for asynchronous data transfer, or even uses short-duration semaphores to read/write some values. This solution requires some sort of idle loop or event listeners unless you want to do busy waiting...
Another option that I think is still quite easy to implement with a new API, is actually the approach of node.js:
Run Lua in a separate thread
Make your whole API of functions that only take callbacks. These callbacks are queued and can be scheduled by your C++ application.
You can even, but do not have to, provide callback wrappers for the standard Lua API.
Example:
local version;
Application.requestVersionNumber(function(val) version = val; end)
Of course this example is riduculously trivial, but you get the idea.
One thing you should know though is that with the callback approach the scripts quickly get highly tiered if you are not careful. While that's not bad for performance, they can get hard to read.
I have implemented a WebSocket handler in C++ and I need to send ping messages once in a while. However, I don't want to start one thread per socket/one global poll thread which only calls the ping function but instead use some OS functionality to call my timer function. On Windows, there is SetTimer but that requires a working message loop (which I don't have.) On Linux there is timer_create, which looks better.
Is there some portable, low-overhead method to get a function called periodically, ideally with some custom context? I.e. something like settimer (const int millisecond, const void* context, void (*callback)(const void*))?
[Edit] Just to make this a bit clearer: I don't want to have to manage additional threads. On Windows, I guess using CreateThreadpoolTimer on the system thread pool will do the trick, but I'm curious to hear if there is a simpler solution and how to port this over to Linux.
If you are intending to go cross-platform, I would suggest you use a cross platform event library like libevent.
libev is newer, however currently has weak Win32 support.
If you use sockets, you can use select, to wait sockets events with timeout,
and in this loop calc time and call callback in suitable time.
If you are looking for a timer that will not require an additional thread, let you do your work transparently and then call the timer function at the appropriate time in the same thread by pre-emptively interrupting your application, then there is no such portable thing.
The first reason is that it's downright dangerous. That's like writing a multi-threaded application with absolutely no synchronization. The second reason is that it is extremely difficult to have good semantics in multi-threaded applications. Which thread should execute the timer callback?
If you're writing a web-socket handler, you are probably already writing a select()-based loop. If so, then you can just use select() with a short timeout and check the different connections for which you need to ping each peer.
Whenever you have asynchronous events, you should have an event loop. This doesn't need to be some system default one, like Windows' message loop. You can create your own. But you should be using it.
The whole point about event-based programming is that you are decoupling your code handling to deal with well-defined functional fragments based on these asynchronous events. Without an event loop, you are condemning yourself to interleaving code that get's input and produces output based on poorly defined "states" that are just fragments of procedural code.
Without a well-defined separation of states using an event-based design, code quickly becomes unmanageable. Because code pauses inside procedures to do input tasks, you have lifetimes of objects that will not span entire procedure scopes, and you will begin to write if (nullptr == xx) in various places that access objects created or destroyed based on events. Dispatch becomes comnbinatorially complex because you have different events expected at each input point and no abstraction.
However, simply using an event loop and dispatch to state machines, you've decreased handling complexity to basic management of handlers (O(n) handlers versus O(mn) branch statements with n types of events and m states). You decouple handling but still allow for functionality to change depending on state. But now these states are well-defined using state classes. And new states can be added if the requirements of the product change.
I'm just saying, stop trying to avoid an event loop. It's a software pattern for very important reasons, all of which have to do with producing professional, reusable, scalable code. Use Boost.ASIO or some other framework for cross platform capabilities. Don't get in the habit of doing it wrong just because you think it will be less of an effort. In the end, even if it's not a professional project that needs maintenance long term, you want to practice making your code professional so you can do something with your skills down the line.
I'm refactoring a project that I did not design. It is written in C/C++ for linux. The project has a major client component that looks like this:
Client -> Output Queuing Library (OQL) -> Controller
Client
Messy semi-complex code, poorly designed (hodgepodge of OOP approximations using singletons/namespaces, just weird in many places - but it works)
Custom protocol implementation (not my protocol, cannot modify)
Shared Library
Multi-threaded
Multiple threads call the OQL api, ie multiple threads output
Accepts commands from controller via API
Produces massive unsequenced output which is affected but not necessarily directly (and definitely not 1:1) by the controller input)
Output Queuing Library (OQL)
Simple clean code, not really designed for it's current workload (was never meant to queue, was actually originally just writing to stdout and then a message queue was shoe-horned in)
Shared Library
Single-threaded
Exposes API which accepts many types of data from the client and builds textual representations of this data
Inserts data into a sys V message queue
Controller
Executable
Single-threaded
Elegant, fault tolerant C++ which makes extensive use of boost
Written from scratch by me, the only part of the project I've been allowed to completely "fix" so to speak
Interacts with client library via API to initiate connection to server
Saves data produced by Client and read from OQL into database in another layer
So the problem essentially boils down to this, the controller is single threaded and calls many API functions in the client library. Scenarios resulting from Controller calling Client API.
Normal (98%+)
Controller calls client API function
Client API function does magic internally
API function returns true
Client receives data as a result of magic in step 2, in another thread of execution and calls OQL put function from a secondary thread
OQL writes data to message queue, queue either blocks or does not block but neither matter since the controller's main thread of execution is running and processing data.
Success!
Problem Scenario
Controller calls client API function
Client API function immediately produces result and BEFORE returning calls OQL put function from the main thread of execution in the Controller
OQL writes data to the message queue and one of the following happens:
Message queue is not full, does not block, everything returns and the controller processes the new data in the message queue and life moves on happily
Problem Scenario Message queue IS full and DOES block
Now what I'm sure you can see is in the problem scenario, which is rare, the main thread of execution is blocking on a full message queue and also no data is being processed off of the other end of the queue since the controller is single threaded...
So yes it's a bit of a mess, and no I'm not happy with the design but I've gotta figure out the best way to solve this without rewriting all of these interactions.
I'm trying to decide between:
Digging into the client, synchronizing all of the threads to a single I/O thread that interacts with OQL
I have basically zero faith that someone after me will not come in and break this down the road, introduce massive bugs and not be able to understand why
Introducing a writer thread into OQL
Takes a simple class and complicates it significantly
Introduces funny problems
Doesn't the queue need a queue at that point? Since data has to get transported to the writer thread
Really just typing up this question was probably the best thing I could have done, since my thoughts are much more organized now...but does anyone have any input to offer here? Is there some design pattern I'm not seeing which would not require massive refactoring, and are my concerns overblown on either of these? I'm not even sure if it's possible for anyone to provide meaningful advice here without knowing all angles of the problem, but I appreciate any insight you guys can offer.
Change client to return an error when the Q is full so the controller can make an intelligent decision about how to continue.
You could change the Controller to use a second thread to do the reading from the message queue (and just post the data to a much larger buffer, internal to the Controller, to be read by the main Controller thread).
I'm developing a project and I have to make a wrapper to some hardware functions.
We have to write and read data to and from a non-volatile memory. I have a library with the read and write functions from the seller company. The problem is that these functions should be called with a delay between each call due to hardware characteristics.
So my solution is to start a thread, make a queue and make my own read and write functions. So every time my functions are called, the data will be stored on the queue and then in the loop thread will be actually read or written on the memory. My functions will use a mutex to synchronize the access to the queue. My wrapper is going to be on a dll. The main module will call my dll init function once to start the thread, and then it will call my read/write functions many times from different threads.
My questions is: Is it safe to do this? the original functions are non reentrant. I don't know if this is going to be a problem. Is there a better way to do this?
Any help will be appreciated.
Sorry I forgot something:
-The language to be used is C++
-The main program will call my wrapper dll but also will call other modules (dlls) that are going to call the wrapper dll.
Adding a mediator in this context is a pretty typical solution so you aren't out in the weeds here. I would say you would need to implement this because the original functions are not reentrant. Assuming, of course, that you own the access to the hardware. (i.e. You are the driver.) If other people can get access to the same piece of hardware, then you're going to have to come up with some higher level contract. Your thread then provides the ordered access to the driver. You'll find that the mediator will also allow you to throttle.
The hard part it seems is knowing when it is okay to make the next call to the device. Does it have some sort of flag to let you know it is ready for reads and writes? Some other questions: How do you plan to communicate state to your clients? Since you are providing an async interface, you'll need to have some sort of error callback registration, etc. Take a look at a normal async driver interface for ideas.
But overall, sounds like a good strategy to start with. As another poster mentioned, more specifics would be nice.
I am currently working on a server application that needs to control a collection devices over a network. Because of this, we need to do a lot of parallel programming. Over time, I have learned that there are three approaches to communication between processing entities (threads/processes/applications). Regrettably, all three approaches have their disadvantages.
A) You can make a synchronous request (a synchronous function call). In this case, the caller waits until the function is processed and the response has been received. For example:
const bool convertedSuccessfully = Sync_ConvertMovie(params);
The problem is that the caller is idling. Sometimes this is just not an option. For example, if the call was made by the user interface thread, it will seem like the application has blocked until the response arrives, which can take a long time.
B) You can make an asynchronous request and wait for a callback to be made. The client code can continue with whatever needs to be done.
Async_ConvertMovie(params, TheFunctionToCallWhenTheResponseArrives);
This solution has the big disadvantange that the callback function necessarily runs in a separate thread. The problem is now that it is hard to get the response back to the caller. For example, you have clicked a button in a dialog, which called a service asynchronlously, but the dialog has been long closed when the callback arrives.
void TheFunctionToCallWhenTheResponseArrives()
{
//Difficulty 1: how to get to the dialog instance?
//Difficulty 2: how to guarantee in a thread-safe manner that
// the dialog instance is still valid?
}
This in itself is not that big a problem. However, when you want to make more than one of such calls, and they all depend on the response of the previous one, this becomes in my experience unmanageably complex.
C) The last option I see is to make an asynchronous request and keep polling until the response has arrived. In between the has-the-response-arrived-yet checks, you can do something useful. This is the best solution I know of to solve the case in which there is a sequence of asynchronous function calls to make. This is because it has the big advantage that you still have the whole caller context around when the response arrives. Also, the logical sequence of the calls remains reasonably clear. For example:
const CallHandle c1 = Sync_ConvertMovie(sourceFile, destFile);
while(!c1.ResponseHasArrived())
{
//... do something in the meanwhile
}
if (!c1.IsSuccessful())
return;
const CallHandle c2 = Sync_CopyFile(destFile, otherLocation);
while(!c1.ResponseHasArrived())
{
//... do something in the meanwhile
}
if (c1.IsSuccessful())
//show a success dialog
The problem with this third solution is that you cannot return from the caller's function. This makes it unsuitable if the work you want to do in between has nothing to do at all with the work you are getting done asynchronously. For a long time I am wondering if there is some other possibility to call functions asynchronously, one that doesn't have the downsides of the options listed above. Does anyone have an idea, some clever trick perhaps?
Note: the example given is C++-like pseudocode. However, I think this question equally applies to C# and Java, and probably a lot of other languages.
You could consider an explicit "event loop" or "message loop", not too different from classic approaches such as a select loop for asynchronous network tasks or a message loop for a windowing system. Events that arrive may be dispatched to a callback when appropriate, such as in your example B, but they may also in some cases be tracked differently, for example to cause transactions in a finite state machine. A FSM is a fine way to manage the complexity of an interaction along a protocol that requires many steps, after all!
One approach to systematize these consideration starts with the Reactor design pattern.
Schmidt's ACE body of work is a good starting point for these issues, if you come from a C++ background; Twisted is also quite worthwhile, from a Python background; and I'm sure that similar frameworks and sets of whitepapers exist for, as you say, "a lot of other languages" (the Wikipedia URL I gave does point at Reactor implementations for other languages, besides ACE and Twisted).
I tend to go with B, but instead of calling forth and back, I'd do the entire processing including follow-ups on a separate thread. The main thread can meanwhile update the GUI and either actively wait for the thread to complete (i.e. show a dialog with a progress bar), or just let it do its thing in the background and pick up the notification when it's done. No complexity problems so far, since the entire processing is actually synchronous from the processing thread's point of view. From the GUI's point of view, it's asynchronous.
Adding to that, in .NET it's no problem to switch to the GUI thread. The BackgroundWorker class and the ThreadPool make this easy as well (I used the ThreadPool, if I remember correctly). In Qt, for example, to stay with C++, it's quite easy as well.
I used this approach on our last major application and am very pleased with it.
Like Alex said, look at Proactor and Reactor as documented by Doug Schmidt in Patterns of Software Architecture.
There are concrete implementations of these for different platforms in ACE.