Best and fast way to AllocMem within an interrupt :Semaphores ?

[Piru]

You can't use semaphores from an interrupt (or anything that might call Wait()).

AllocMem() itself does not break forbid (or disable), so why not just call AllocMem directly?

[Piru]

That would be true if it was an interrupt, but in this case it's not: The OS is inside PutMsg to your msgport, not AllocMem. At least I can't think of any condition in which the port could be PutMsg()d while the memory list is in inconsistent state. This at least with mp_Flags of 3.

PA_SOFTINT might be another story.

[Piru]

Well even though softint would break forbid (IIRC it doesn't), it still is quite unlikely that someone would send message to your msgport while memlist is inconsistent. So IMO PA_SOFTINT is pretty much as safe.

[Piru]

I got various processes running, some of which can allocate memory to send messages to the HD recorder process very frequently, so if softint breaks forbid maybe it could happend.

And all memory allocation routines Forbid/Permit internally. How can them PutMsg inside memory allocation/free?

[Piru]

@ChaosLord

I'll pretend you never suggested that.

[Piru]

It's no interrupt, that is: it can't be in the middle of memory allocation/free.

Using static size buffers that are "large enough (to certain point)" is rather silly IMO. It wastes memory and will fail if something needs more memory after all.

If you're worried about performance, you can use simple pooled allocation with Allocate/Deallocate.

[Piru]

They're all based on Allocate()/Deallocate(), so they're quite fast while memory is not fragmented.

However, FreePooled() is a bit special: It gets really slow due to the puddle scanning to find the proper memory header to call Deallocate() on. This gets exponentally slow.

AmigaOS 3.9 BB2 fixed this by using the new AVL tree binary balanced tree instead of simple linked list for the puddles.

[Piru]

In the worst case every 8 bytes is allocated and free. This way it's the (memory_area_size / 8 / 2) nodes to walk thru before you find the correct chunk.

At Allocate(), if the large enough free memory chunk is after such alteration of allocated and free chunks, it needs to walk thru all of them to find the large enough one.

At Deallocate() it needs to walk all free chunks until it finds chunk to merge with (or to insert after).

Needless to say, fragmentation is bad. If you need absolute speed, I suggest using object cache for the time critical things, or other similar methods.