 | | threads —Mike McFarlane
|
| | | Hi, I'm struggling to get threads working (in a simple motor speed matching program), the code just keeps hanging up. I've isolated the problem to when I restart the threads after killing them if a bumper is hit in the bumper_task() function. The (...) (23 years ago, 14-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | |
| | | | | Re: threads —Mike McFarlane
|
| | | | Hi again, I'm now totally stuck with this problem. I've spent all day at it, stepping through the code line by line with key presses. I've marked the point that the code appears to hang in left_control_task (). Someone please help, please. Thanks (...) (23 years ago, 15-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | |
| | | | | | Re: threads —Albert Huang
|
| | | | | some suggestions: 1) random_delay = random()/1000000; LegOS uses 16 bit integers, meaning the largest value an integer can have is something like 65535. The above statement is meaningless 2) (...) If you kill a thread, make sure it's still a valid (...) (23 years ago, 15-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | | |
| | | | | | | Re: threads —Mike McFarlane
|
| | | | | | Thanks Albert (...) still (...) How do I check this? There are no other tasks that can kill threads apart from this one. I also checked process IDs after creation and before killing. Best regards, mike (23 years ago, 16-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | | | |
| | | | | | | | Re: threads —Albert Huang
|
| | | | | | two of your threads terminate shortly after being started (...) as far as I know, legOS provides no functionality for determining whether or not a thread is alive or not. You need to keep track of this yourself (e.g. using a variable/flag that gets (...) (23 years ago, 16-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | | | |
| | | | | | | | Re: threads —Mike McFarlane
|
| | | | | | Albert (...) yea, I see what you are getting at. I am sure that I was hitting the bumper while the threads were still alive, but I will check again. I think this also points out some of the dangers of just dumping in some poorly thought out dummy (...) (23 years ago, 17-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | | | |
| | | | | | Re: threads - bug in the firmware? —Mike McFarlane
|
| | | | Hi again I have now totally stripped down my code to a minimum and I am still having problems with the code hanging up. I can see nowhere where there can be a fault. I am a long way from being an expert, but is it possible there is a bug in the (...) (23 years ago, 16-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | |
| | | | | | Re: threads - bug in the firmware? —Eric Swalens
|
| | | | | (...) As pointed by Albert Huang, you cannot call kill() with an "invalid" pid. Actually, the comment above kill() in tm.c says: //! kill a process /*! \param pid must be valid process ID, or undefined behaviour will result! The function updates (...) (23 years ago, 16-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | | |
| | | | | | Re: threads - bug in the firmware? —Michael Obenland
|
| | | | Hi Mike, your problem is not because of an error in legOS. But what you do is that you start your subroutines and then you leave main()! Leaving main means that all your allocated memory is freed. The following will do the job: ---...--- cut here (...) (23 years ago, 17-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | |
| | | | | | Re: threads - bug in the firmware? —Mike McFarlane
|
| | | | | ;-) That worked a treat, thanks Michael. (thanks for the other little corrections in the code too). mike (...) Mike, (...) your subroutines and then you leave main()! Leaving main means (...) memory is freed. The following will do the job: (...) (...) (23 years ago, 17-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | | |
| | | | | | Re: threads - bug in the firmware? —Ross Crawford
|
| | | | | (...) Note also since bumper_task() is an infinite loop, and you never use pid1, you could save one thread by doing this: int main(int argc, char *argv[]) { pid2 = execi (&left_task, 0, NULL, PRIO_NORMAL+2, DEFAULT_STACK_SIZE); pid3 = execi (...) (23 years ago, 17-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | | |
| | | | | | | Re: threads - bug in the firmware? —Mike McFarlane
|
| | | | | | Hi Ross (...) you (...) What are the advantages and disadvantages of this method as opposed to the one I used? mike (23 years ago, 18-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | | | |
| | | | | | | | Re: threads - bug in the firmware? —Ross Crawford
|
| | | | | | (...) Advantage: Less memory used (each thread needs a block of memory in the kernel, I'm at work & can't remember the struct name off hand). In the case under discussion, this doesn't make much difference, but in a large project, memory use can (...) (23 years ago, 21-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | | | |
| | | | | | Re: threads - bug in the firmware? —Michael Ash
|
| | | | (...) I would strongly suggest changing this to while(1) msleep(bignumber);. Otherwise you're hogging the processor doing nothing important, which could do bad things to any compute-intensive tasks you may have going. It'll also use slightly less (...) (23 years ago, 18-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | |
| | | | | | More on threads —Michael Obenland
|
| | | | (...) Of course you are right. I think it is a bad programming style not to give your program the ability to terminate but to run in an endless loop. But what is the penalty for this bad style? I've done some investigations and here are the results: (...) (23 years ago, 18-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | |
| | | | | | Re: More on threads —Mike McFarlane
|
| | | | (...) ability to terminate but to run in an endless loop. But This is not true of an embedded system though which will have to run 'forever'. (...) priority of NORMAL+4. So, the (...) any time slice at all. NO time slice or just a very small chunk (...) (23 years ago, 19-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | |
| | | | | | Re: More on threads —Michael Obenland
|
| | | | (...) Digging through tm.c gave me the impression, that main will indeed get no time slice. So I wrote another test program: ---...--- #include <conio.h> #include <unistd.h> pid_t worker; int work_task(int argc, char *argv[]); int main() { int i; i (...) (23 years ago, 19-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | |
| | | | | | Re: More on threads —Michael Ash
|
| | | | (...) I recall that legOS's priority model is pretty rigid. If a thread with a higher priority never yields, threads with lower priority will never get any time. When I write legOS programs, I generally just have everything run at PRIO_NORMAL. That (...) (23 years ago, 19-Jan-02, to lugnet.robotics.rcx.legos)
|
| | | | |
