Synclib.mutex

Does anyone know how SyncLib.mutex works on RISC OS.

You have a situation like this

mutex_lock(a);
some_code;
mutex_unlock(a);

The code is entered the first time (1st pass) then ‘some_code’ is interrupted and the code is re-entered (2nd pass). The interrupt stalls the 1st pass and enters mutex_lock on the 2nd pass where it waits for the 1st pass to finish which can never happen as RISC OS doesn’t multitask.

What am I missing?

Colin,
mutex_lock waits (cpuevent_wait()) until “a” is available to be locked.

In your case when your process go on pass 2, a is already locked and so the mutex_lock will wait forever, given that a is owned by your process…

you can try to use mutex_try_lock instead, that will lock only if a is not locked already otherwise it will return false.

if you really want to use mutex_lock then you need to add some checks before you use it in your case.

Makes sense?

you could try something like:

if ( a != MUTEX_LOCKED ) mutex_lock(&a);
some_code;
mutex_unlock(&a);

It’s not code I’m writing.

I was looking at some NETBSD usb source code that uses mutex – the version we have just disabled/enabled interrupts. I then found synclib and thought maybe this could be used but it occurred to me that without preemptive multitasking it can’t work as the first pass will never unlock if it is interrupted and the mutex lock is called again.

I just figured that my understanding must be wrong as otherwise why would the riscos code include mutex.

I just figured that my understanding must be wrong as otherwise why would the riscos code include mutex.

Good point, generally speaking cooperative multi-tasking is lock-free in user-space because there is not an “uncontrolled concurrency” between threads (which would requires mutexes).

However SyncLib can be useful on RISC OS when using things like RTSupport and/or DThreads. Especially with RTSupport where threads can be always in the “potentially runnable” pool.

Good luck!