Re: [ECOS] [SMP]serious bug in synchronisation primitives

[sandeep <shimple0 at yahoo dot com>]

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?

sandeep
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss