Well, you have to get the Semaphore object across threads, which is harder

A semapore is an object managed by the kernel and you can get that object by passing an ID of some sort to a call such as:

CreateSemaphore(int semID, Semaphore* semaphore);

Like you said... calcs have limited resources. You could define a fixed number of semaphores in your kernel. Then each task could register for a semaphore with the CreateSemaphore API. So... 2 (or more) tasks could register for the same semaphore and use the ReleaseSemaphore/WaitForSemaphore APIs to effectively sync with each other.

Piece of cake

Lol sure... I think the ThreadID works well as a semaphore.  Do you have a link to some docs on this?

I'll see if I can come up with some docs for you.

Each thread (or task) would have its own unique ID and each semaphore would have its own unique ID. That way two independent threads can utilize the same semaphore for syncing purposes -- so I don't think using thread ID as a sem ID would be a good idea for this reason.

edit: here is a link to the VxWorks reference manual. Take a look at the semLib chapter.

http://www.sls.psi.ch/controls/help/howto/vxworksHOWTO/VxWorks_Ref_Man.pdf

What happens if two threads try and access the same thing at the same time?

Nothing special.  Technically, it won't be at the same time without multiple cores, which the calculator does not have.

Nice to see the project is coming along (I don't visit that often anymore, sadly...). About semaphores: would that actually be necessary in this context? If the kernel routines use too much 'modern' access control, wouldn't that cause huge lags?


EDIT: oh, something to that effect has been stated already. Sorry to bother.

You're still keeping this TI-73/83+ compatible, right?

Ah ok. I thought it might be 73 compatible since it barely requires much modifications if I remember. Not really that necessary, though, as very few people use the TI-73. (even less than the 81, if I remember). It's only sold in USA, too.

That looks nice. That lines that gets deleted very fast it's CLEAR, right? Otherwise it might be good to make sure key sensitiveness isn't too high.