RE: Panic in OSMalloc??
RE: Panic in OSMalloc??
- Subject: RE: Panic in OSMalloc??
- From: "Vishal Shetye" <email@hidden>
- Date: Fri, 11 Jan 2008 22:23:34 +0530
Hi,
First of all thanks for your quick reply.
What all you are saying is true but it is like our product is almost at
release phase and I see panic only on iMac not on MacPro or Macmini and that
too very infrequently.
So thanks for suggestion, may be I should consider this change.
________________________________
thanks
- vishal shetye
-----Original Message-----
From: Rick Macklem [mailto:email@hidden]
Sent: Friday, January 11, 2008 9:33 PM
To: Vishal Shetye
Cc: email@hidden
Subject: RE: Panic in OSMalloc??
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