RE: Panic in OSMalloc??
RE: Panic in OSMalloc??
- Subject: RE: Panic in OSMalloc??
- From: Rick Macklem <email@hidden>
- Date: Fri, 11 Jan 2008 11:03:17 -0500 (EST)
On Fri, 11 Jan 2008, Vishal Shetye wrote:
Hi Brian,
Could you please explain what are the consequences of calling OSMalloc with
some spin lock held.
I'm using lck_spin_lock() to lock a global variable before OSMalloc and
release it once the item allocated has been added to a queue.
I'm not Brian and won't pretend to be, but... the short version is that
you can't block holding a spin lock, as I understand it. (Since any other
thread would just be busy waiting in a tight loop waiting for the lock
while the thread holding the lock blocked, it wouldn't make much sense,
even if the implementation permitted it.)
Besides returned NULL value, is there any other difference between
OSMalloc() and OSMalloc_noblock()?
In case OSMalloc_noblock() returns NULL can I try allocation immediately?
Probably not a good plan. I'd guess that it will keep returning NULL
until some other thread frees up some memory. Since looping on
OSMalloc_noblock() would not block, it would hog the CPU. (In a
traditional non-preemptive BSD kernel, the system would be hung, but I
don't know diddly about the Mach side of things, so I don't know if other
Mach threads would still be able to run and eventually release memory.)
(Hopefully others with more expertice on the Mach side will chime in.)
How I handle these situations (not saying it's the right way, but it is
an easy way:-) is:
- malloc new structure, blocking as required, until I have one
- lock
- search list and add new one, as required
- unlock
- free new one, if it wasn't needed (Yep, this case results in an
extraneous malloc/free.)
Another easy way (not so easy if multiple lists and structures are
involved):
tryagain:
- lock
- search list
- if new one needed
- if no new one allocated
- attempt non-blocking allocation
- if new one is allocated
- add to list
- else
- unlock
- do blocking allocation of new one
- goto tryagain
- add to list
- unlock
- if new one allocated, but not used
- free new one
Others will probably have more clever approaches. Personally, I'm a big
KISS (keep it simple stupid) proponent, unless it is a critical path w.r.t
performance.
Have fun with it, rick
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden