Attention is currently required from: laforge, pespin.
1 comment:
File library/Mutex.ttcn:
Patch Set #2, Line 19: port MutexPT LOCK; /* port for LOCKing the mutex */
Ah ok so you are using the port queue based on the the sender to decide/filter whether to operate/wait for the lock operator.
Exactly. I am additionally including a Mutex reference in each message, which for now is used to make sure that a wrong component cannot unlock the Mutex that was locked by another component. This is not really needed, since we can just remember component reference of the Mutex locker. But we may develop this idea further, enabling components to have more than one Mutex identified by a reference.
I'd have done that with 1 port and then maintaining a queue of vc_conn lock operations internally in the component, but fine your way too then.
Can you explain your idea a bit more? Not that I am planning to rewrite and debug this again, since it's already a lot of effort spent on trying to scale existing TCs rather than writing new ones. It's just my curiosity.
Ah no erase what I said above. The mutex you are implementing here is no reentrant. If a component calls LOCK operation twice, it will deadlock/timeout.
Yes, the component will fail and terminate due to timeout. But why would you want to lock the Mutex twice? Is this a normal scenario? I could fix this by adding a boolean flag to the `MutexCT`, so that `f_Mutex_lock()` would set it and then return immediately if it's already set. Or fail immediately, if we consider this abnormal.
By implementing it they way I mention you then get a reentrant Mutex.
But I guess your implementation is good enough for what we need here for now.
As I said, I am interested to hear/see what other options we have here and generally open for improvements. But for now this is a poor-man's Mutex that does its job, so I am happy with it.
To view, visit change 38206. To unsubscribe, or for help writing mail filters, visit settings.