[ECOS] [SMP]serious bug in synchronisation primitives
Mon Dec 13 15:32:00 GMT 2004
a dumb question in context of current thread.
since most of the code that calls lock on synchronisation primitive also calls
unlock. but in earlier discussion you mentioned to the effect that there are
cases where code is prepared to deal with returning from lock w/o actually
locking/owning the resource.
why not introduce an additional argument in lock call(s), default value(true) of
that indicates former condition and code passes (false) for latter kind of need.
in latter case code would be examining the return value of lock call and taking
the appropriate actions after examining the wake_reason if needed.
ntrwotr is place holder for argument name that signified 'need to return with
owning the resource' and it's default
within the lock code, for ex. in Cyg_Mutex::lock(cyg_bool ntrwotr) we can do
something like --
if (ntrwotr || result)
locked = true;
owner = self;
this trivial looking approach might not be solving the problem w/o causing other
problems else maintainers might have considered this as a fix to take care of
issue in this thread. i wonder what?
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss