Trying to multithread program. C++/CLI
Hey i'm trying to multithread my program in c++/cli but i'm having problems with creating the threads the code im using is:
Code:
private: Void startThread(){
MoveProj.Velocity = Variables.Velocity;
MoveProj.ProjectilePos = Projectile1.ProjectilePos;
Thread^ MotionThread1 = gcnew Thread(gcnew ParameterizedThreadStart(MoveProj ,MotionThread::MoveProjectile));
Thread^ MainThread = gcnew Thread(gcnew ThreadStart());
}
but i'm getting the errors
Code:
Error 44 error C3350: 'System::Threading::ParameterizedThreadStart' : a delegate constructor expects 2 argument(s) c:\users\gaz\documents\visual studio 2012\projects\projectilemotion\projectilemotion\Simulation.h 344
Error 89 error C3350: 'System::Threading::ParameterizedThreadStart' : a delegate constructor expects 2 argument(s) c:\users\gaz\documents\visual studio 2012\projects\projectilemotion\projectilemotion\Simulation.h 344
Error 45 error C3350: 'System::Threading::ThreadStart' : a delegate constructor expects 2 argument(s) c:\users\gaz\documents\visual studio 2012\projects\projectilemotion\projectilemotion\Simulation.h 345
Error 90 error C3350: 'System::Threading::ThreadStart' : a delegate constructor expects 2 argument(s) c:\users\gaz\documents\visual studio 2012\projects\projectilemotion\projectilemotion\Simulation.h 345
Error 43 error C3867: 'MotionThread::MoveProjectile': function call missing argument list; use '&MotionThread::MoveProjectile' to create a pointer to member c:\users\gaz\documents\visual studio 2012\projects\projectilemotion\projectilemotion\Simulation.h 344
Error 88 error C3867: 'MotionThread::MoveProjectile': function call missing argument list; use '&MotionThread::MoveProjectile' to create a pointer to member c:\users\gaz\documents\visual studio 2012\projects\projectilemotion\projectilemotion\Simulation.h 344
any help with this would be a great help as its for my college computing project and my tutor wants it in relatively soon.
Re: Trying to multithread program. C++/CLI
Well, admittedly the delegate construction syntax is somewhat weird, and the error messages you get when you mess that up are even worse... (The C3867 error message you got is a valuable hint, though.) Your line using the ParameterizedThreadStart delegate would be syntactically correct like this:
Code:
Thread^ MotionThread1 = gcnew Thread(gcnew ParameterizedThreadStart(MoveProj ,&MotionThread::MoveProjectile));
Usage of ThreadStart would look much the same, just the signature required from the worker thread function passed as the second parameter is different (i.e. it takes no parameter).
However, I see two additional, more complex problems with your code:
The first parameter of the delegate constructor is the object on which the member function is to be called. In order for that to work, obviously, the fuction must be a member of the passed object's class (or one of its base classes). This is impossible here since they don't seem to be of the same type (one represents a projectile, the other one a thread), and, as your usage of the dot operator for member access suggests, MoveProj seems to be an instance of a value type, and value types can neither be derived from other types (except for interface implementations), nor can they be derived from.
When passing a value type instance as the first parameter to the delegate constructor, the instance will be boxed, so it can be passed to a parameter of type Object ^, which implies that a copy is made. As a consequence, the worker thread will operate on the boxed copy of the object, hence any changes it makes on the object will not be reflected in the original object. This is probaby not what you intend.
Re: Trying to multithread program. C++/CLI
well here's the full code for my project (everythings in .h files the .cpp files i havn't added in here as i havn't really added much to them)
https://gist.github.com/anonymous/5365228
MotionThread is a class (i named it badly because i didn't understand how to make threads at that point)
so MoveProj is an instance of that class and MoveProjectile is a function in that class.
MoveProjectile takes 2 arguments which are both points but atm i have MoveProjectile as void. ( everything in that function is also commented out as i was getting some strange errors to do with the .X and .Y of the Point).
Re: Trying to multithread program. C++/CLI
o as a bit of extra background, what im doing is a Projectile Motion simulation including wind velocity, gravity and coefficient of restitution.
I use a mouse input (click/drag/release) to take input for the initial release of the projectile and then from there everything is calculated within the program usually in Allformvariables functions, being called from the simulation form which uses a instance of the Allformvariables class called Variables to call the functions. I then want to thread the program so i can have the calculations being done whilst the projectile is moving so as to smooth out the motion. ( i have got a basic version of the program written but the movement is very jumpy)
Re: Trying to multithread program. C++/CLI
Please note that the regulars around this forum usually are rather reluctant to follow off-site links to code, images or whatever, especially when they have been posted by a new user. AFAIK github has a good reputation among developers, so I followed your link, but certainly not everyone here would have done that, so the off-site link effectively lowers your chance to get valuable replies. Better embed code snippets (of reasonable length and in code tags) in your post and attach images or zipped Visual Studio projects.
Although your code looks well-structured, it's somewhat difficult to follow in that view-only form, probably due to its complexity. So I suggest you zip and upload (i.e. attach) your VC++ solution, so I can make use of the IDE to inspect it more efficiently. Please run a clean-up on the project before doing so (separately for the debug and release branches if you've already built both of them). Close the IDE and delete the .sdf file from the solution directory before zipping if there is one; it will be rebuilt automatcally.
Re: Trying to multithread program. C++/CLI
is it just the solution you need or do you need debug files and .sdf file aswell??. never transferred a program between pc's before except as a release :P thanks for all the help your giving though
Re: Trying to multithread program. C++/CLI
It's not the solution file I need, it's the zipped solution directory (including the .sln file), but without anything inside the Debug and Release directories (eliminated by the clean up) and the .sdf file (not subject to the IDE's clean-up run).
1 Attachment(s)
Re: Trying to multithread program. C++/CLI
o okay i got you :P the ipch folder is 1.5mb when zipped though so i'm going to have to upload to mediafire or something unless you don't need that folder.
i've attached everything but that folder though
Re: Trying to multithread program. C++/CLI
No, the ipch folder is not needed. It will be rebuilt automatically by the IDE as needed, much like the .sdf file. Can't recall having ever seen such a folder, at least not of that size, in a C++/CLI project not containing any native modules or referencing large native libraries (like and including the Win32 API), so I didn't see a need to mention it. Can't check that reliably (though it really is of merely marginal importance), nor can I take a detailed look at your project until I'm back at my Windows box tomorrow.
Re: Trying to multithread program. C++/CLI
ahH okay I got ya. Well I have got a few in my code and also so guessing they would increase the size of the ipch folder.
Thanks for all the help by the way.
just as a little extra information on what im actually doing with this project.
Its a projectile motion simulation with air resistance gravity and coefficient of restitution included (I was going to expand it after the project had been given in hence the main menu with new game load game and settings on it)
I have already got a simple prototype of the program written which I could upload but the reason I started to rewrite it was that 1.the code was a complete mess. 2. The motion of the projectile was extremely jumpy due to it calculating the velocity and moving the ball all in one thread using a 1ms timer for the movement so obviously this didn't work cause it also had the time for the processor to calculate everything before moving the ball again. And 3. The equations to calculate the new velocity are very broken and the projectile exponentially rose in speed :P.
So I figured I'd rewrite the program using threads and equations (also classes as my prototype was all in one header file). But then my tutor decided she wanted it in earlier so I had to rush this one without learning what I was doing and obviously this meant I was googleing things and then just trying to figure out how to implement it into my code. So once i manage to get this to work and hand in my final report im going to go through it all learning exactly what everything does. But for now i just need to get the simulation part working to a basic standard lol (ball moves smoothly with correct values).
Hopefully i will be able to do all the mogement of the projectile on my own once the multithreading is working as i already have the code written to move the ball.
(sorry for bad grammar im on my phone)
Re: Trying to multithread program. C++/CLI
Ok, my VC++ 2010 refused to open your VS 2012 project, so I first needed to build a new version 2010 project out of your source files, which took some additional time. Now I can't use Forms Designer on your forms, but that doesn't really hurt by now. So here we go...
First I'll give you some mostly syntactical advice to make your project compile with minimal modifications so mou may further purse your current approach if you want, though I'd actually like to suggest you a different approach, more on that below.
So now I know that your types MotionThread and AllFormVariables actually are reference types, not value types, just your instances of these are implicitly dereferenced variables, which is why you use the value type-like dot operator syntax for member access. Although implicitly dereferenced variables are convenient for developers coming from native C++ because they behave more like native C++ class member or local variales, I personally find them confusing (as already mentioned in earlier threads). This is the fixed version of MyForm::StartThread():
Code:
private: Void startThread(){
MoveProj.Velocity = Variables.Velocity;
MoveProj.ProjectilePos = Projectile1.ProjectilePos;
Thread^ MotionThread1 = gcnew
Thread(gcnew ParameterizedThreadStart(%MoveProj ,&MotionThread::MoveProjectile));
Thread^ MainThread = gcnew Thread(gcnew ThreadStart(%Variables, &Allformvariables::CalcCurrentVelocity));
}
The % prefixing the first parameters to the delegate constructors, which are specific to the use of implicitly dereferenced variables and were missing, were the reason for the C2440 error message.
I also changed the signature of Allformvariables::CalcCurrentVelocity() by removing the parameter which was unused anyway, so it now matches the signature expected by the ThreadStart constructor.
Your global variable timetaken caused a linker error LNK2005 because it was defined non-extern in a header file included by more than one compilation unit. This is a really common mistake with global variables in native C++ which has been discussed quite some times in the Non-VC++ forum section, including how to fix it. However, global variables should be avoided whenever possible in general, and even more so in .NET, so I won't go into more detail about that now. As a quick and hackish fix I turned that variable into a static local variable of Allformvariables::CalcCurrentVelocity() which comes closest to a global variable and was easily possible since it isn't accessed from anywhere else anyway:
Code:
public: void CalcCurrentVelocity()
{
static float timetaken;
Velocity.X = initialVelocity.X + (AirResistance/Area)*timetaken;
Velocity.Y = initialVelocity.Y + Gravity*timetaken;
}
However, as is obvious now, the variable, zero-initialized as a static, never gets changed, so the velocity remains constant. This is why that "solution" is quite hackish.
There also were two (IIRC) C4715 warnings which I didn't pursue further, but you should definitely do that, since they usually indicate severe bugs waiting to sneak up from behind.
And while we're talking about warnings: There's absolutely no point in using floats rather than doubles in .NET except when you're storing a whole lot of them (for instance, I have an app where I store hundreds of thousands of objects containing some of them), so you can expect a considerable reduction of your memory footprint from using floats, or perhaps when you're working with/supporting interfaces that deal with them. In calculations they actually are quite counter-productive: In any case they're converted to double before performing the calculation, even if the expression being calculated exclusively contains floats, and then converted back when you store the result in a float variable. And changing that would eliminate the majority of the many warnings your code generates, unless you have turned them off (which, in fact, I was really tempted to do, but that's generally not recommended).
And now for the alternative approach I'd like to suggest, as mentioned at the start of this post: Starting two worker threads for so tiny tasks as you're doing now definitely is overkill, even more so as your thread functions currently are "one-shots", performing their tiny tasks and then terminating (the worker thread just started!). Doing things like that inline in fact is much more efficient, and you didn't even take any care of synchronization yet...
You wrote you experimented with a timer (am I right to assume you meant a System::Windows::Forms::Timer?) but weren't satisfied with the result. There are two important things worth to know about this kind of timer, which are due to the way it is implemented by the framework: (1) No matter how low you set its Interval property, it will never fire faster than every 15.625 ms (64 Hz). (2) The timer is in no way reliable in terms of real-time processing. If the OS or your app is busy, any number of timer ticks may be missed.
Still I think you can put up a decent timer-based design for your app, therby avoiding the increased complexity incurred by multithreading. I'm thinking of a design based on the idea of a game loop, yet not with an actual loop but with event-driven iterations done in a timer tick handler. (IIRC this basically is the common game loop implementation approach used with the XNA framework.) The trick is to not base your timing on counting timer ticks, but instead use a reliable independent timestamp source. The System::Diagnostics::Stopwatch class is a great candidate for this. Per my experience it can be expected to have a nice resolution of less than one microsecond and is reliably isochronuous. It can assume the place of your timetaken variable.
Finally, a word about your random number generation: Re-seeding the random number generator based on time() each time you need a random number is even much worse than not seeding it at all in most cases. This has been discussed quite some times in the Non-VC++ section as well. And I'm not going into detail about that as well, since unnecessarily using native library functions in a .NET program should be avoided whenever possible anyway. The .NET framework provides the System::Random class you can use instead.
Re: Trying to multithread program. C++/CLI
Wow thank you :P.
i'll implement the fixes but i think i will pursue the alternative method you suggested.
My first prototype of this program was using a System::windows::forms::timer i was thinking that was probably causing the majority of my movement problems but i couldn't find any suitable alternative whilst searching (was always searching for timers though so that would probably explain that).
Also thank you for the advice on Random number generator. i searched for a while on that one and ended up doing it the way my tutor told us to do in Basic last year just altered slightly for c++/cli. so i will alter that to use the System::Random class. instead.
Thank you for all the help you've given me, been asking my tutor about this for the last 2 weeks and she's been utterly useless whereas you've helped me and expanded on what i have been doing 'wrong' (for lack of better word) hopefully i will be able to get this finished now thanks for all the help
!!!EDIT!!!
It works thank you so much. The projectile moves a bit fast at the moment but thats my problem, ill just change the velocity to be alot lower so it only moves like 2 pixels at a time instead of 10 it should slow it down enough that you can see the movement. It's smooth aswell unlike the timer version (i'm using a game loop)
havn't quite got the loop sorted atm it enters into an infinite loop because i'm not polling for user input but thats fixable thank you so much
Re: Trying to multithread program. C++/CLI
okay sorry to ask this but i have another problem which i've searched for (i saw a thread awhile ago but can't find it now)
My program won't run on other computers (when built as a release) if they don't have a c++ compiler installed. i've tried it on my laptop (which i built it on) and it works fine, my mates laptop (which has visual studio 2010 with c++) and it worked fine. and then i have tried it on a PC which has Visual basic but no c++ compiler on it and it didn't open and showed no error messages or anything and another PC again with no c++ compiler and again it didn't load and showed no error messages.
obviously theres some dependencies which there missing but one of them has installed Vc++ 2012 redistributable and it still didn't work. he is on a lower .net framework than me (he's on 4.3 im on 4.5) but i'm pretty sure they have the same files just slightly updated. any ideas??
Re: Trying to multithread program. C++/CLI
Quote:
Originally Posted by
welsh4evr
!!!EDIT!!!
It works thank you so much. The projectile moves a bit fast at the moment but thats my problem, ill just change the velocity to be alot lower so it only moves like 2 pixels at a time instead of 10 it should slow it down enough that you can see the movement. It's smooth aswell unlike the timer version (i'm using a game loop)
havn't quite got the loop sorted atm it enters into an infinite loop because i'm not polling for user input but thats fixable thank you so much
The actual exact idea behind my suggestion was to not use an actual loop. This blocks your GUI thread and renders your app irresponsive, as you have noticed. Instead use a timer tick handler to do your incremental calculations and base your time scale on a Stopwatch. That way your simulation time scale would not depend on the unreliable timer tick, just the display rendering would do. The timer easily supports a frame rate of 24 fps (40 ms interval) as commonly used in movies, which should be sufficient unless you're going to write an ego shooter. The fact that the system will drop timer ticks when under stress I'd rather consider an advantage here: On a heavily stressed system your app would be in a pinch anyway with all that calculating and rendering. With my proposed design your simulation would still be based on a stable time scale, just the display may be a bit sluggish under heavy system load, and a user running your app under such conditions IMO should be prepared for this.
As you're owner-drawing your projectile, you should call Invalidate() on your form after modifying the simulation state in your timer tick handler. (Personally, I'd have taken a different approach to drawing the projectile where that wouldn't be needed, but to some extent that's a matter of personal taste.)
Re: Trying to multithread program. C++/CLI
Quote:
Originally Posted by
welsh4evr
obviously theres some dependencies which there missing but one of them has installed Vc++ 2012 redistributable and it still didn't work. he is on a lower .net framework than me (he's on 4.3 im on 4.5) but i'm pretty sure they have the same files just slightly updated. any ideas??
The target system needs to have the target .NET framework version installed, and that's 4.5 in your case. (I've never heard of a .NET 4.3, BTW.) For a C++/CLI program, however, that's not the only dependecy: It also needs the matching Visual C++ runtime redistributable.
Re: Trying to multithread program. C++/CLI
yea i've never heard of a .net 4.3 either actually but i figured i'd take his word for it. I'll try and inclue the .NET framework installation with my setup program will be easier than making people install it manually. i'll also include the 2012 redistributables.
So you think i should use a Timer and on every timer tick draw everything whilst continuously doing the calculations required??
Or do you mean Update and Draw on one timer tick but use the stopclock just to keep track of the time taken to put into my calculations??
Re: Trying to multithread program. C++/CLI
Quote:
Originally Posted by
welsh4evr
So you think i should use a Timer and on every timer tick draw everything whilst continuously doing the calculations required??
I'm not quite sure what you mean by "continuously", but if that involves a loop, then definitely no.
Quote:
Or do you mean Update and Draw on one timer tick but use the stopclock just to keep track of the time taken to put into my calculations??
Yes, that's what I meant. It's easy when the calculations you perform in any simulation step just depend on time and some parameters that remain constant over the simulation run (of course it's absolutely fine to change parameters between simulation runs). If, however, your calculations also depend on results obtained in the previous step, it may become more complicated, since the timespan elapsed between steps may not be constant (which actually is the gist of the game loop approach).
But don't do any actual drawing in the timer tick handler. Just update your simulation parameters and call Invalidate(), which will result in OnPaint() being called, where you then do the actual drawing based on the updated simulation parameters, much like you're already doing in the code you uploaded.
To reduce CPU load caused by repainting, you may just invalidate the area that actually has changed rather than the entire form, sort of what is described in http://forums.codeguru.com/showthrea...92#post2005192. But CPU load probably won't be so dramatic either way.
