OSDev.org

Wrote another small tutorial. This time on thread (and CPU) synchronization primitives. This one won't teach how to use them, just how to implement them. For anything beyond spinlocks I expect one to have a working scheduler (for obvious reasons).

My userspace semaphores are more simple than what Linux does, but I implement general (counting) semaphores anyway. Using them as mutexes is trivial.

No idea if it's of any use for anyone, but ... well ...

Anyway, as you'd guess, the address is this time:
http://www.cs.hut.fi/~tvoipio/threads.html

But, have you continue write your <How to write a small compiler>?
It's not done yet! I'm waite long time for it!

Here's a tutorial on writing a compiler: http://compilers.iecc.com/crenshaw/

just to let you know that your HTML layout fooled my navigator (mozilla 1.6) and printer, so i'm getting over-large fonts and missing one word per line (dunno exactly why)

hmmm ... i'm not sure to fully understand the solution you suggest to the problem of a thread that does a "wait" in userspace and a process that does a "post" in the meantime ...

I understand where the problem is, but not fully that stuff of "future posts" count.

hmmm ... i'm not sure to fully understand the solution you suggest to the problem of a thread that does a "wait" in userspace and a process that does a "post" in the meantime ...

I understand where the problem is, but not fully that stuff of "future posts" count.

Pype.Clicker wrote: just to let you know that your HTML layout fooled my navigator (mozilla 1.6) and printer, so i'm getting over-large fonts and missing one word per line (dunno exactly why)

Funny. The layout is developed with Firefox, and I've tested it (although not the specific article) with IE 6 too, but I'll investigate.

I'm trying to use relative size for everything (so scaling font-sizes scales the whole thing), and there's some separate rules for printing, so it is possible that I've broken something. Good that you mention anyway. Have to see if I can fix that.

edit: Ok, so at least print-preview indeed loses a few last characters of each line. Printing to a PostScript file here seems to work, except the margin's go wrong. URG.

I don't what happens in display though, since it works fine here. Are you running Mozilla on what operating system (Linux version suffers from some RENDER bugs at least.) If you can send me a screenshot, that would help too.

edit more: I admit of doing some ugly things in there. I was actually thinking of doing a cleaner layout. I like the look of the current, but the problems you mention aren't the only ones it has.

gxl117 wrote: But, have you continue write your <How to write a small compiler>?
It's not done yet! I'm waite long time for it!

Oops, yeah. Haven't written more of it. Sorry.

I be completely honest, I was kinda hoping that people would forget it.

But I guess I should complete it anyway. Good to know someone's actually waiting for it.

Pype.Clicker wrote: hmmm ... i'm not sure to fully understand the solution you suggest to the problem of a thread that does a "wait" in userspace and a process that does a "post" in the meantime ...

I understand where the problem is, but not fully that stuff of "future posts" count.

Ok, hmmh.. Have to try and clarify it, as I admit the description of the solution is not that great.

Anyway, the idea is that if a post() went to kernel and there's nobody waiting in there, then post()ing on a kernel semaphore records that the next wait()er was already conceptually released before it reached the kernel.

So the wait():n thread becomes a logical waiter when it does the locked "DEC". Since it can be released before it reaches the wait-queue, a kernel-side semaphore is used for counting how many such "early" releases we've done, and let's those wait()ers pass immediately.

Does that clarify? I'll try to find a better explanation for the tutorial in the near future.

Ok, so I rewrote the part about using a kernel semaphore for handling the problem with the userspace semaphore. I removed the whole idea of "future posts" and hopefully made the point clearer.

I also now mention it explicitly that the end-result is that syscall_fusem_post() and syscall_fusem_wait() become just normal kernel-side semaphore's post() and wait().

mystran wrote:
I don't what happens in display though, since it works fine here. Are you running Mozilla on what operating system (Linux version suffers from some RENDER bugs at least.) If you can send me a screenshot, that would help too.

No, the display was almost perfect (except in low res, the mapping/regions/process figure gets out of the margins, as it is quite large...) Only the print-out resulted in useless paper (damn, i hate wasting paper )

Ah, I know the figure goes out of margins, since it's large. Since it's about 800 pixels I figured I'd just let it run out of margin, since the margins are there to keep the text-width sane (in hope to make it more readable).

Could draw a new version of that figure though. It's not nearly as good as I wanted...

Pype,

Urgh. Bad me. I had the main content's width set to "40em" which for screen is ofcourse fine, and scales nicely and everything, but on paper that is just plain STUPID thing to do.

So now I have a "@media print" rule to reset width to "auto" when printing. Good that it was mentioned. Should now work better as long as the media-rules are supported (Mozilla does).