Attention is currently required from: fixeria, laforge.
pespin has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206?usp=email )
Change subject: library: add generic Mutex API for parallel components ......................................................................
Patch Set 2:
(1 comment)
File library/Mutex.ttcn:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/38206/comment/47ac92a8_0632c... : PS2, Line 19: port MutexPT LOCK; /* port for LOCKing the mutex */
But why would you want to lock the Mutex twice? Is this a normal scenario?
Sure reentrant mutexes are a thing :) This is usually only needed in more complex scenarios than what we aim here though. This can be used for instance to implement semaphores, which eg. allow up to N-concurrent users where N can be defined.
Can you explain your idea a bit more?
Yes, you have 1 port which has LOCK and UNLOCK operations.
alt { [lock_count == 0] pt.get_call(LOCK) -> sender { lock_sender = sender; lock_count++; pt.send_response(sender, LOCK); } [lock_count > 0] pt.get_call(LOCK) -> sender { if (lock_count > 0) { if(and sender != lock_sender) { error(); } else { /* Make the component wait until mutex is unlocked: */ lock_queue := lock_queue & { sender }; return; } lock_sender = sender; lock_count++; pt.send_response(sender, LOCK); } [lock_count == 0] pt.get_call(UNLOCK) -> sender { errror(); } [lock_count > 0] pt.get_call(UNLOCK) -> sender { if (sender != lock_sender) error(); lock_count--; pt.send_response(sender, UNLOCK); if (lock_count == 0) { if (lengthof(lock_queue) > 0) sender := lock_queue[0] //TODO: HERE pop lock_queue[0] from queue /* Tell first component waiting in the queue that it finally acquired the lock: */ pt.send_response(sender, LOCK); lock_count++; } }
}