[Bug 1814] SMP race condition between stack free and dispatch

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1814

--- Comment #7 from Joel Sherrill <joel.sherrill at oarcorp.com> 2012-08-08 10:05:02 CDT ---
(In reply to comment #6)
> It looks like there is deferred frees for malloc, but not for workspace.
> However thread stacks can be handled by an allocator hook now, so maybe SMP
> variants can be provided with some default hooks that use malloc and deferred
> free?

Possible but that just adds another layer of complexity. 

Plus as the thread indicates we think we see this sometimes in uniprocessor
systems.

I think having the deferred free in the score heap is a good solution. The
overall footprint won't change except for the rare system that hacks the source
to remove malloc(). It is just moving code.

If the stack free is deferred, then the question is... is there anyway AT ALL
the stack memory from the deleted thread to be reallocated BEFORE it is
switched out.

+ malloc() is only valid from tasks
+ task create is only valid from tasks
+ another task won't be able to run until we complete the dispatch

Is there any window in this solution given the current big lock?

I would like to evolve to finer granularity locks but am concerned there will
be lots of cases that need analysis before we have confidence. Marta.. if you
all have documentation on the overall critical section structure/rules/types
you used in your effort, that would be appreciated.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.