Re: Mutex oddities with v1.0.0

> > > t_obj is only used when waiting for lock, to link the tasks which are > waiting > for the lock. Not after lock has been obtained. > Task can only sleep on one lock at a time; it’s not possible to wait for 2 > simultaneously. > So semaphore and mutex using the same t_obj while waiting is ok;

Re: Mutex oddities with v1.0.0

> On Nov 6, 2017, at 5:23 PM, Jitesh Shah wrote: > > Alright, > I think I have an idea of whats going on here. > > So the structure of my code is like this -> > os_mutex_pend(); > .. trigger operation here .. > os_sem_pend(); // Wait for operation to complete. ISR calls

Re: Mutex oddities with v1.0.0

Jitesh: You are indeed correct: the current code will not allow that. This will be addressed in the 1.3 release. Thanks for pointing this out! Will > On Nov 6, 2017, at 5:23 PM, Jitesh Shah wrote: > > Alright, > I think I have an idea of whats going on here. > > So the

Re: Mutex oddities with v1.0.0

I’d start by looking for memory corruption. You could try adding guard variables around your send_mutex(), and see if anything stomps on them. Another option could be to change mutex_release() to write something other than 0 at mu_owner, and then add a conditional hardware watchpoint which looks

Re: Mutex oddities with v1.0.0

I agree that a mutex should never have a null owner and a nonzero level. Unfortunately, my first guess is some form of memory corruption: it seems like a null value accidentally got written to `mu_owner`. I could be missing it, but I don't see any logic error in the mutex code which could cause

Re: Mutex oddities with v1.0.0

What this looks like to me is that there was a nested pend without the same number of releases. Maybe some path out of some code that is rarely hit where a mutex is granted but not released? Just a guess... > On Nov 5, 2017, at 8:26 PM, Jitesh Shah wrote: > > Hey Guys,

Mutex oddities with v1.0.0

Hey Guys, I am running v1.0.0 branch (0db6321a75deda126943aa187842da6b977cd1c1). Seeing some strange mutex behaviour. So once in a bazillion times, a mutex fails to release. Here is how the structure looks like when it fails: > (gdb) p/x send_mutex > $1 = {mu_head = {slh_first = 0x0}, _pad =