Transactional and GC Intrinsics, 3rd Revision

Attempting to combine the intrinsicts I developed in the latest entry about transactional intrinsics (a RISC approach) with GC intrinsics. (Note: in this text "or" means inclusive, "either ... or" means exclusive. Damn English language and its logical inadequacies).

watch (r | w), %ptr* [, %set]

Watch for read or write events on %ptr, possibly adding it to %set.

touch (tx | gc), (r | w), %ptr* [, %gclog]

Report read or write activity on %ptr to transaction or garbage collection system. If activity is being reported to the gc system, %gclog is required.

discard [r | w,] %set*

Stop watching the specified type of activity on %set.

result = validate [r | w], [%set*]

Yield true if no conflicts of the specified type has taken place on %set. If %set is omitted, check for any conflict.

log (undo/buf), %ptr*, %log

Log an action in either undo or write-buffering style, storing the information to %log.

commit %log*

Perform all actions described in %log if it is a write-buffering log, and finalize the actions in either case, discarding the log.

rollback %log*

Undo all actions in %log if it is an undo log, and abort the actions in either case, discarding the log.

suspend %set*

Suspend the current thread until someone accesses a location in %set.

gc_alloc [tx,] type, options

Allocate garbage-collected memory with type and options. If tx is specified, the allocation will be cached and not repeated if the transaction aborts.

safepoint %gclog

Possibly context switch or do garbage collection. %gclog must contain at least one entry for each location that has been written to since the last safe point.


Problems with this intrinsic set: 1) there is no way to create logs or sets and maintain them, 2) log would seem to be inseparable from a touch w, which would mean they should probably be combined, 3) there is no obvious way to indicate how conflicts are to be resolved (which thread wins, for instance). I also need to add the gc allocator stuff, and scheduler intrinsics.

The next revision will have the scheduler operations and more metastate, perhaps conflict stuff.