Post
by zapmaker » Mon Dec 17, 2012 3:25 am
Bob - I'm impressed that you got it to run on the raspberry pi, I didn't even think of that as an option!
I've seen lockups before in the code and almost 100% of the time it was due to one thread stomping on the data of another due to incorrect/non-existent data protection. There is a chance you uncovered such code that, for some reason, isn't manifesting itself on the other platforms. I did hammer on the code pretty well on all three platforms, but multithreaded issues can be difficult to reproduce quickly. I understand that this may not be a multithreaded issue and could be something specific to the pi.
Regarding multithreaded coding, every dialog in Qt is run in a separated thread, additionally, I've fired off some threads to do various work. Now, I'm lazy as far as implementing critical sections/mutexes when I don't have to, and Qt has an architecture that allows you to almost avoid all use of the multithreaded primitives if you use their signal/slot model of inter-thread communication, which was the approach I chose. It is possible I didn't catch all conditions.
When you set an atomic variable, i.e. an integer - CPUs do the set in one instruction, so the set does not need to be protected. Example in GrblHoming code would be Gcode::setShutdown(). This sets shutdownState = true, and is a direct call from one thread into another with no protection (vs. signal/slot), but that is ok, since it is an integer. If the code said shutdownState++, that would need to be protected with a critsec/mutex, because that compiles down into multiple assembly instructions. That is the kind of thing that I am looking for - a call from one object to another directly that is not an atomic operation.
I'll take a look and if I see any issues during connection with the controller, if I find anything I'll let you know.
zapmaker
Shapeoko #668
Dual-Y axis, belts outside, DW660 | Author of Grbl Controller 3.0 |
http://zapmaker.org