This is the mail archive of the ecos-patches@sources.redhat.com mailing list for the eCos project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Nick Garnett wrote:
True. It makes the probability 0.001% rather than 1%. Hmm.. is this good enough still though. Anyone else's opinion before I potentially flog a dead horse?Jonathan Larmour <jifl@eCosCentric.com> writes:Hi Nick, I was looking over the patch while going through the backlog and was wondering about the following function. While the scheduler is locked inside the function, it obviously may well not be outside. In that case the thread being pointed to by current may have exitted and the memory (at least partially) reused since the last invocation of cyg_thread_get_next(). For example the unique id in the thread structure could be intact, but the list pointers scribbled on.Well, I also added an assignment in the thread destructor to zero the thread id. So if the memory has been reused, even for another thread, the id check will fail and it won't touch the list links.
Ah, I was assuming the user would be forced to use a valid thread handle since they "have the threads", but if they used cyg_thread_get_next i.e. they don't know what thread it really is, then I guess not.+cyg_bool_t cyg_thread_get_info( cyg_handle_t threadh, + cyg_uint16 id, + cyg_thread_info *info ) +{ + cyg_bool_t result = true; + Cyg_Thread *thread = (Cyg_Thread *)threadh; + + Cyg_Scheduler::lock(); + + if( thread->get_unique_id() == id && info != NULL ) + {Why pass in the id at all if it must match the thread handle?
For the same reason as above. The thread object memory may have been
reused in the interim. Double checking the id give us a simple
integrity check.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |