No need for Semaphore when data size is <= 32 bit ?

[Jose]

Would I be correct in assuming that all data that is smaller than 32 bits doesn't actually need a Semaphore when shared between tasks and/or processes cause it's allways valid (the CPU reads/writes to it at once so there's no way a task/process will be interrupted in the middle). ?

[Piru]

You wouldn't.

Hint: How to read the value and modify it in arbitrary way and have that in single, atomic operation? Just reading or writing the value doesn't give anything useful, or at least I can't think of any use for that.

Even if you would only read or modify it, even the modify might not be atomic operation (it isn't with PPC).

If the code is m68k only, and if the code only does atomic read or update operation, then it would work. But like I said, such conditions aren't met often.

[Karlos]

Jose wrote:
Would I be correct in assuming that all data that is smaller than 32 bits doesn't actually need a Semaphore when shared between tasks and/or processes cause it's allways valid (the CPU reads/writes to it at once so there's no way a task/process will be interrupted in the middle). ?

How can you guarentee the read write operation will not be interrupted? It could be preempted to switch out before it gets the chance to write the modified data back. Your operation would need to be atomic, as Piru says. I am not sure off the top of my head but IIRC, only instructions like TAS etc have an atomic read/write cycle.

[Doppie1200]

Thread safety is not about data size.
It is about to guarantee resources are not used by another process.

[Steady]

And, of course, the TAS instruction is a no-no on Amiga anyway as it can screw up chipset timings.

As everyone else is saying, if something is public and could potentially be changed by another process, protect it with a semaphore.

It's not the size that matters.

[itix]

@Karlos

Certain operations are atomic. For example if you wish to set flags
atomically you can have:

or.l #1, 4(a4)

This operation is never interrupted and there is nobody else who would modify data in between. Of course this works in assembler only because C compiler might not work this way.

[itix]

That is, normally in C you would use something like

Forbid()
globalflags |= 1;
Permit()

when in 68k assembler coder can use single or.l instruction without Forbid()/Permit() arbitration.

This is sometimes used when dealing with Intuition windows.

[Piru]

It should also be pointed out that Forbid/Permit arbitration should be used when there is no long, blocking operation done using the locked object. If there is some such operation (such as scanning a list for example), semaphore should be used.

[Jose]

I actually forgot to mention that the thread/process involved only does a very tiny instruction with the variable, that most likely corresponds to one instruction in assembler.

@Piru
"Just reading or writing the value doesn't give anything useful, or at least I can't think of any use for that."

Raising a counter;) But maybe this wouln't be atomic in PPC ?

[SamuraiCrow]

No.  On a PowerPC you'd have to load into a register, add 1, and store the register back to memory.  3 opcodes=Non-atomic.

[Jose]

Pah, 68k rules:)
Ok I'll use a damn Semaphore for the thing... :-x

[itix]

@Jose & SamuraiCrow

It is possible implement atomically incrementing counter in PPC asm without using Forbid()/Permit() or Semaphore arbitration. But better use other more portable methods than asm.

[Jose]

I'm now really getting into a part of my code that uses this. I had some more thought into it. There are 2 reasons I can remember to use a semaphore: protect access from another task and, more serious (cause it can lead to a crash or a program malfunction), data integrity. Even if raising a counter is not atomic in PPC, I'm sure the write cannot be interrupted (you don't get a 32 bit counter's read with half the current and half the previous value), so data integrity is not a problem here.
So to avoid using data that is not uptodate I decided to not use a semaphore, but a software interrupt in the task that's using it. The timer.device is about the only one that can be used with an interrupt  from what I've read on the RKM's libraries, and that's the one I'm receiving messages from, after wich some actions are take and counter is raised, so it's all good.

Any caution/problems/advice with this solution, or it's just brilliant ? 8-)