Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
100 user(s) are online (52 user(s) are browsing Forums)

Members: 1
Guests: 99

MigthyMax, more...

Headlines

 
  Register To Post  

MutexAttemptWithSignal
Just popping in
Just popping in


See User information
I must be missing something very basic here:

APTR mtx AllocSysObjectTags(ASOT_MUTEXASOMUTEX_RecursiveFALSETAG_END);
MutexObtain(mtx);
uint32 sigmask MutexAttemptWithSignal(mtxSIGF_SINGLE);


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?

Go to top
Re: MutexAttemptWithSignal
Just can't stay away
Just can't stay away


See User information
@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.

Go to top
Re: MutexAttemptWithSignal
Just popping in
Just popping in


See User information
@salass00

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


Edited by sTix on 2021/8/23 8:32:18
Go to top
Re: MutexAttemptWithSignal
Just popping in
Just popping in


See User information
@salass00

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

BYTE sigbit AllocSignal(-1);
APTR mtx = AllocSysObjectTags(ASOT_MUTEX, ASOMUTEX_Recursive, FALSE, TAG_END); 
MutexObtain(mtx); 
uint32 sigmask = MutexAttemptWithSignal(mtx, 1 << sigbit);



Go to top
Re: MutexAttemptWithSignal
Just can't stay away
Just can't stay away


See User information
@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.

Go to top
Re: MutexAttemptWithSignal
Just popping in
Just popping in


See User information
@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!

Go to top
Re: MutexAttemptWithSignal
Just popping in
Just popping in


See User information
@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.

Go to top
Re: MutexAttemptWithSignal
Just popping in
Just popping in


See User information
@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.

Go to top
Re: MutexAttemptWithSignal
Home away from home
Home away from home


See User information
@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?

Go to top
Re: MutexAttemptWithSignal
Just popping in
Just popping in


See User information
@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.

Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project