[mercury-users] thread safety

[Michael Day]

> To explain more fully, yes, there is one shared mutex, so a foreign_proc 
> marked non-thread-safe will not run concurrently with any other 
> foreign_proc so marked (or itself). However, if a number of 
> foreign_procs run one after the other, and need to share data, e.g. 
> through a global variable, this will not be safe. read_to_matrix and 
> write_as_tiff are Mercury predicates that call a number of foreign_procs 
> in sequence to do their stuff. Although each foreign_proc called will 
> not run concurrently with any other, there is nothing stopping the 
> sequence being interrupted, e.g. read_to_matrix running its first 
> foreign_proc which sets a global, followed by write_as_tiff in another 
> thread running a foreign_proc that modifies that global, followed by 
> read_to_matrix running its second foreign_proc that accesses that global 
> (which has been screwed up by the other thread).

In Prince we mark all foreign procs as being thread_safe for this 
reason, as the compilers enforcement of locking is at the wrong level of 
granularity for many situations and it is safer to enforce it ourselves 
at a higher level.

Personally I would rather rename thread_safe/non_thread_safe to 
something less misleading, like mutexed/non_mutexed or whatever. Thread 
safety is a much deeper issue than wrapping an individual predicate in a 
lock; if the Java "synchronized" keyword was called "thread_safe" people 
would just add it to every method to make everything safe :)

Michael

-- 
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------