I just realized that an almost equal sound occurs in the New-Jersey dialect, as the characteristic thick 'r'. Also see
formatting link
.
I disagree with this philosophy. This mutex should be kept internal to the allocator. If the heap is created with a 'shared' flag, then it is created internally, otherwise it is set to NULL.
I see. But it can be argued that this is a system design error, not an error in the allocator.
But now, with this priority elevation, the low priority task forces the medium priority task to wait. For as long as the low priority task wants to run (until it releases the resource)!
--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)
It's been too many years since I lived East for me to recall how folks from Joisey spoke. :< (except, of course, "joisey" and "earl"/oil).
I think I will see if DECTalk supports it and just type in your name phonetically and see what comes out. Heck, it can't mangle it much worse than it does *mine*! :>
[snips]
That's how I do things in bigger (fleshier) RTOS's. Here, I am trying to balance hidden complexity with that which is exposed to the developer for maintenance "manually".
It lets the sizeof(Heap) be a bit smaller as well as letting me (developer) decide how and when to use the Mutex-es to my best advantage (the applications on which I am deploying this are pretty tightly constrained, resource wise).
It also makes it clear in each *invocation* of a service whether that service *might* have to compete, or not. E.g., if I invoked one of these routines in an ISR with the mutex parameter non-NULL, it would be a red flag to me that I was "asking for trouble". OTOH, if I invoke it with the flag set to NULL, it "self-documents" the fact that there can be no competitors at this time
Note that that can change, dynamically!
E.g., if I EXPLICTLY enter a critical region (take a lock on a particular mutex that, by convention, protects some set of resources), then I can invoke these routines freely WITHOUT needing a malloc-specific Mutex -- that would just be extra overhead!
Yet, outside such a region, I *would* want the protection of a Mutex (assuming competition for *that* Heap exists). If I bury it in the Heap struct, then I have to put the flag in all calls (i.e., it can't be a "configure/create-time" option). So, I *do* put the flag there! Except, instead of "TRUE" or "FALSE", it is "NO MUTEX REQUIRED" or "USE *THIS* MUTEX"
Style issue?
It *can* be. It's just a typical scenario that can lead to deadlock (hence the title of the thread :> ). E.g., if I take X and get ready to take Y but you have taken Y and are waiting for X, we're both screwed. "Design error".
OTOH, since it is a multitasking environment, you never know when a low priority task is going to run and "happen" to end up with a resource that some higher priority task might happen to want at the same time. "Luck of the draw".
E.g., that low priority task might be doing background garbage collection -- "when nothing of greater importance needs to be done". It might (temporarily) need some resource that the "real" application also needs. But, the "real" application doesn't seem to be needing it, right now. I.e., the real appplication is idle -- maybe waiting for input from the user?
Foolish to tell the low priority task that it can't TEMPORARILY use that resource -- heck, that's the whole point of having the low priority task "mop things up" when there is spare time to do so!
Of course, coincidence could cause the user to provide the input that the high priority task was waiting *just* after the low priority task took the resource. Now, high priority task is ready to run, goes looking for the resource and has to block.
In the meantime, it (or something else) has caused a medium priority task to become eligible to run so that task preempts the low priority task.
See
formatting link
If you don't address these sorts of possibilities in your resource management (e.g., memory -- whether managed in a heap or as "buffer pools"), then your allocation scheme is immaterial -- your RTOS is broke! :>
Yes. Presumably, it *will* release the resource. Otherwise you have a design error. :> It would be no different than the (a?) high priority task seizing the resource indefinitely -- and thereby preventing any other task from ever using it.
But, you *can* control whether or not your code (the low priority task's code) releases a resource or not. You *can't* (usually) control the timing of these other external events and other dependencies that affect when a given task decides to wake up, etc.
So, you design the system (in this case, resource manager) so that if you "get unlucky" and things queue up in some perverse order ("priority inversion"), then the system does what it can to help things untangle themselves.
It's *engineering*, after all... :>
I think I've sorted out (in my head) how to tackle this. Now I just have to figure out an efficient implementation. Then, see what else I can harvest from that implementation to enhance the rest of the RTOS.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.