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

[Peter Wang]

On 2007-02-08, Jonathan Morgan <jonmmorgan at gmail.com> wrote:
> On 2/7/07, Peter Wang <wangp at students.csse.unimelb.edu.au> wrote:
> >
> >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.

Right.

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

Right.

> making this code thread safe (though I would not think that
> the general description of thread safety made this portable).

No.  Consider if a program calls read_to_matrix simultaneously in two
separate threads.  Assume their executions are interleaved:

(T1)	Image1 = open_and_read_tiff_file(File1),
(T2)	Image2 = open_and_read_tiff_file(File2),
(T1)	Width1 = get_width(Image1),
(T2)	Width2 = get_width(Image2),
	...

Now, open_and_read_tiff_file works with a statically allocated data
structure.  The second call to open_and_read_tiff_file will clobber the
data structure before T1 is finished with it.

Peter

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