Hellish question

Is this thread safe? Should we put a mutex?

No affinity

Protect data. Not code.

Yes.
1. But then is that mutex safe?
2. Should we put a mutex just to make sure?
3. GOTO 1

>>4
You don't understand mutexes.

I have acquired the spinlock for this thread.

You may not post in it.

>>6
HURR DURR RACE CONDITION

>>7
HURR DURR
Back to the imageboards, please.

What if one of Xarn's scripts acquires the mutex and then dies?

I'm fine with using a mutex, but provide only a MutexLock object which unlocks the board in the destructor or after a certain timeout. This way we can be safe even if an exception is thrown, FrozenHURR appears, or anything else.

This board uses software transactional memory, i. e. no muteces, locks and other 1970's bullshit is needed.  Welcome to XXI century.

>>9
after a certain timeout
I'm sick of this fucking bullshit. I'd need more than 32 bits to count the number of retarded ENTERPRISE SOFTWARE SOLUTIONS that I've seen failing because some synchronization primitive timed out due to memory pressure causing severe paging in the host.

"Ehh... Uhh... Well, it sure won't take more than 10 seconds, right?"

I have another idea: since people dislike crashes, let's just write a crash handler that jumps to some random function when there's a crash. Problem solved!

Use STM and all your problems will be solved.¹

USE CLOJURE!!!!!!!!!!!!!

>>9
if an exception is thrown
NO EXCEPTIONS

>>14
I imagined a Larry Wall lecture and Larry says this and one listener interrupts him and rises from his seat and firmly shouts NO EXCEPTIONS and I lol'd.

>>15
Larry Wall had a GCC switch named after him (-Wall) despite the fact that C wasn't invented yet.  It fell into relative obscurity until Stallman made it popular by assaulting OpenBSD where everyone uses it.  Perl is born.

>>16
Actually, that flag means Warning: all, as in, print all warnings.

>>17
Surely you jest.