site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Aug 28, 2008, at 1:26 PM, alejandro wrote: Terry, Kind regards, Alejandro Brian Bergstrand <http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2 _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... Yes, a mutex can be taken during memory allocation. You can use the _noblock variants of the allocators but you have to be prepared for a NULL return. I addition, the _noblock variants will always return NULL when trying to allocate over 8KB (at least last time I checked which was Tiger). Thank you for your answer. It has been a good direction. You are right, disk reads (invalidating caches or otherwise) are not the problem. After a lot of tests I have found that any memory allocations done by a non-realtime thread cause the blocking (about 10mS) in the realtime threads. Because the problem arises very unfrequently (average every hour) the testing is very slow. So my question is, Is there any system-wide locking mechanism when a malloc is performed? If this is the case, I will create my own memory pool for this purpose. This email sent to site_archiver@lists.apple.com