In perl, all user data is stored in scalars (SV*s).

What if the user mutable shared data, shared scalars were allocated from a read-only memory section?

Every time the user attempted to write to them, an exception would be raised.

When an exception occurs, the operation, whatever it may be, is re-done within the auspices of a critical section having temporarially set the section read-write. It is set back to read-only before the critical section ends.

As I understand it (on x86), the read-only/read-write status of a section of memory is an attribute of its LDT entry. These are read and written using single opcodes (SLDT/LLDT) and so the process of switching between read-only to read-write and back ought to be pretty quick.

The steps are:

1. enter exception handler.
2. enter critical section.
3. set the attributes of the shared data memory section to read-write.
4. reattempt the excepting operation (opcode?)
5. reset the shared data memory section read-only.
6. exit critical section
7. exit exception handler
8. continue with original program at the next operation.

As a critical section cannot be preempted, this effectively locks the shared data without the need for semaphores.

The removal of semaphores from the picture, vastly reduces the complexity of the problem, and vastly reduces the overhead of checking for locks.

The absence of the requirement for semaphores means that the same (existing) code for manipulating non-shared SV*s can also be used for shared SV*s, with no impact on performance for operations on non-shared data.

All locking becomes redundant. And serialisation of write accesses to shared data is dealt with entirely by a single mechanism that is controlled by the CPU itself, that of raising exceptions.

These will only occur when writing. And only when writing to shared data.

All other accesses are entirely free of any impact attributable to the provision of shared data.

The only other impact is that when variables are declared shared, they get allocated from the shared (most times, read-only) memory section.

• Can this work?
• Would it be faster?
• Could it be retro-fitted to perl 5?
• Is there any merit in it for perl 6 (or Parrot or other implementation)?

Win32/win64 certainly have all the primitives to implement this. I suspect, but do not know, that many/most other OSs (on x86 at least) have similar primitives in order to implement it. What about other platforms/hardware?

I do not have the requisite XS/perlguts skills to try it, or reach a conclusion on whether it could be done there. So I am throwing the idea out there to see what pople think?