[mercury-users] announced: libtiff foreign interface (caveats)

[Ben Schmidt]

>> The mutex only protects a single foreign_proc at a time.  It doesn't
>> prevent two instances of read_to_matrix or write_as_tiff from executing
>> at the same time, for example.  You'd need to get rid of the two globals
>> in libtiff_io.c and pass them around as parameters.
> 
> Unless I misunderstand what you are saying, I wouldn't read the
> reference manual that way at all.  For a start, I would certainly say
> that the reference manual states that two copies of a foreign
> procedure marked non_thread_safe cannot be executed at the same time.
> In addition, I would say that the statement "All non-thread-safe
> foreign language code shares a single mutex." means that not more than
> one foreign procedure marked not thread safe can be executed at the
> same time, making this code thread safe (though I would not think that
> the general description of thread safety made this portable).
> 
> Please clarify this statement.

The reference manual and your interpretation both seem correct to me, as 
does the earlier comment. Perhaps you just didn't realise that 
read_to_matrix and write_as_tiff were Mercury predicates, not foreign code?

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).

Ben.

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------