thread ready code

[User Name:]

I have bunch of functions for my pmm, but I came up with the problem: "What if another thread or process(assuming I ever get to that point) calls and allocates a page already assumed free in another that is paused(there inherently has to be some time between checking if a page is free and marking it used)?"

If tried to make an alloc_lock variable, but some functions that use the lock call other functions that use the lock so it causes the "nested" calls to react as though allocation is locked.

How should this be handled?

If any mod can think of a better title, go ahead and change it. I had no idea about what I'm asking about is called, but I'm sure there has to be a name for it.

[phantomotap]

It can be hard or even impossible to "tack on" "thread safety" to an existing API that is inherently not thread safe. (This goes for exceptions as well if you program in C++).

[Edit]Wow. With my switching two words in that context that made no sense whatsoever.[/Edit]

Soma

[User Name:]

> I'm also assuming that this lock object is not local to a thread.
Yes. It's really a function that would be called from threaded code, which I guess makes it threaded too. If one of the threads calling it gets interrupted in between checking and allocating, and another calls it, it would have the same effect.
What do you mean by "TLS" status?

[phantomotap]

^_^

I'm listing to music, watching a video tutorial, and working on my administrator "toolkey". You need to forget what I said. The way I said what I said made no sense. It will only do you harm.

[Edit]
To be specific, since I swapped two terms, it would actually cause you more problems without solving the issue.
[/Edit]

[Edit]
Now then, let me try to explain what I was suggesting without barfing on the words.

(I'm assuming that the "pmm" state is correctly handling thread issues except for this one issue related to allocation and deallocation.)

The easiest thing I could think of, assuming my conditions were met:

The "lock" object can be modified, however you like, to have "Thread Local Storage" status. This "lock" object can then obtain a real "mutex" or whatever. The "lock" object, unique to each thread, can then export functionality based on its own address (*) allowing you to immediately return from a "lock" acquisition within the same thread when the real "mutex" has already been obtained.

You would use it the same as you are using your existing "lock" mechanism, you just need to do a bit of wrapping.
[/Edit]

Soma

* This should be unique to a thread, and the "fix" I describe should happen naturally, but I suppose it really depends on the "TLS" mechanism.

[User Name:]

I'm kinda at a loss as to what to do. Thread/Process local storage is exactly what I don't want. I want it locked for all threads and processes. It's that some of my functions that lock then call other functions that lock. For example, alloc_pages(uint x) marks x pages as being used, but locks, then checks each before marking them, and then calls alloc_page to mark the individual pages, then unlocks. If the lock is set(when called by alloc_pages it is), alloc_page returns with an error(because allocation is locked). Physical pages are managed system wide, that's why I need a complete lock. This function will be called from functions everywhere within my (eventual) kernel.

PS: pmm = physical-page memory manager

[phantomotap]

pmm = physical-page memory manager

O_o

That is so very not the definition I was using. I was thinking various parallel image processing techniques related to matrices.

What I was talking about wouldn't work and is far beyond inappropriate for the task.

*shrug*

Depending on your kernel design you would actually need to export a mechanism backing support for "TLS" as part of your "PMM".



If you are writing kernel level code, you are obviously "locking" at the wrong level, using the wrong kind of "lock", or not exporting enough functionality from your "lock".



In your case, you are at least "locking" at the wrong level, but you may have other problems as well. In general, you should design a hierarchy of shared resources, lock those resources in order of "lowest impact", and always respect that hierarchy. In your case, you should not even have a "locking hierarchy". Both `alloc_pages' and `alloc_page' should very likely call `alloc_pages_core' which implements the necessary mechanisms for many variations of such functionality by inspecting the parameters passed to that function requiring a single kernel level "lock". Usually "locking" primitives are expensive, far more so than simply comparing an extra integer, so you shouldn't go about nesting them if you don't have to do that.



That said, you should probably export at least one "counting semaphore" from your kernel. (You may want to add a "counting spinlock" for fun.)



Now then, it is possible, though extremely difficult*, to implement memory management using "lock free" operations. (It isn't the algorithm; it is the implementation.)

Soma

* By extremely difficult, I mean I gave up chasing bugs after 18 months working on my own kernel and went with a "locking" implementation.

[User Name:]

I've basically come to the understanding that FOR NOW, I'll make it always report unlocked. Basically, I'm trying to write code that will work a long time from now. So I'm working way to far ahead without an interface for working so far ahead, I'm planning for multitasking without a way to tell processes/threads apart. I'm months if not years away from getting multitasking, at which point I'll implement mutexes(apparently that's what they're called), then I'll have to come back to get my alloc_lock() and alloc_unlock() functions to work correctly.

Thanks for your suggestions. it's good to see I'm in good company, you being a former OS dev'er!

[phantomotap]

If you only even ever have support for a single thread of execution for a single user, you'll find many device "IRQ" easier to deal with if your kernel properly supports sharing resources. That doesn't mean you must have "locking" primitives, but they are nice to have around.

Thanks for your suggestions. it's good to see I'm in good company, you being a former OS dev'er!

I've failed to do almost everything. ^_^;

Soma

[User Name:]

My ultimate goal is non-reentrant interrupts with preemptive multitasking that supports multiple processes with multiple threads each. IRQs in my opinion, are the jobs of drivers. A driver may hook an unused interrupt and configure their device to use it.

My kernel (concept ) is more of a cpu/memory driver; it provides an interface for drivers and to setup interrupts, processes to multitask, and processes to access memory. My ultimate goal is extensibility.