MutexAttemptWithSignal

I must be missing something very basic here:



Like I expect, the MutexAttemptWithSignal call hangs. If I use Scout to signal the task, it continues. That's also what I would expect. But sigmask is 0. If I understand the documentation correctly it should have been SIGF_SINGLE, shouldn't it?

@sTix

The SIGF_SINGLE signal is used internally by the semaphore/mutex functions to signal when a semaphore/mutex has become free so it can't be used in the way that you are using it.

@salass00

Ok, good to know. So in other words I'm tricking myself to believe that the mutex is obtained by signaling manually?

@salass00

Thanks for helping out. The snippet below should be safe though? It behaves in the exact same way.

@sTix

To be honest I'm not really sure what the purpose of non-recursive mutices is (as they do not save memory or CPU time AFAIK) and what exactly the correct behavior should be for your code.

What happens however for your code is that after returning from Wait(SIGF_SINGLE|sigmask) MutexAttemptWithSignal() checks if it is now the owner of the mutex in question and if it is it always returns zero indicating that the mutex was successfully obtained.

@salass00

I guess it's possible to shave off a few bytes and cpu cycles by not caring about ownership. Not being owned by a thread makes it possible to throw them around, one thread locking, another one unlocking and so on. I don't know if this is applicable on AmigaOS though. I'm just doing some random experiments to learn the Amiga way of doing things. The only use case I care about is testing AttemptWithSignal ;) Didn't turn out the way I expected, but I learnt something. Thanks!

@sTix
Your code _should_ work as you expect and return the signal if that is the reason for MutextAttemptWithSignal() returning, or zero if the mutex is obtained.

How do you trigger with the correct signal? It may be you only posted example code and left out the debug output telling you which signal you have to trigger from the outside, but as it is shown here you can't really see the correct signal to send :)

Disclaimer: I've never used the new mutex function, so I don't know more than what the autodocs and examples indicate.

@graff

I don't use any code to signal the task, the code is nothing but the lines you see above. I use the Scout utility which seems to peek into the task struct to see what signals the task is waiting on. And just like salass00 wrote above, it's waiting for SIGF_SINGLE|sigmask, so I signal using sigmask only and it unblocks as expected, but then returns 0. I do get a valid sigbit from AllocSignal also, not -1.

@sTix

If you attempt that mutex on a different process, you will get the result you expect.

As Frederik already said It's returning 0 because the process your attempting the mutex on already owns it.

Do you have real world use case where you need anon recursive mutex to be used in this way?

@broadblues

No, I don't have any real use case. I was just surprised by this behaviour while experimenting with timers. I thought that I could attempt to lock, hang until a timeout signal arrived and then verify that the timeout occured. This only makes sense when having multiple threads of course, for testing purposes I thought that I could skip the threading part, because I'm lazy. I didn't expect the mutex to keep track of ownership since it non-recursive. I don't understand why it does that, it's unneccesary and leads to unintuitive results IMO. It's just my opinion though, in ISO C11 the outcome of the same operation is undefined, so I guess the behaviour can be considered correct.