[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-glpk] GLPK re-endrant

From: Robbie Morrison
Subject: Re: [Help-glpk] GLPK re-endrant
Date: Wed, 08 Jul 2009 21:39:25 +0200
User-agent: Thunderbird (X11/20080306)

Hello all -- there could be issues for single-threaded
programs too ... but hopefully not -- Robbie


I just consulted Robbins and Robbins (2003) on the
topic of thread-safe functions.  I note that some
so-called non-reentrant functions can also fail within
a single-threaded process, if called in a interleaved
manner.  The example Robbins and Robbins cite uses
'strtok', a token extracting function provided by the C
standard library.  (This call has also been the topic
of recent discussion too.)


It would be useful to confirm that GLPK cannot fail in
a manner similar to 'strtok'.

That is, I assume a single-threaded simulation can
sequentially call various GLPK functions on distinct
GLPK problem objects without unexpected consequences.

Or, put the other way (as I understand it), data
remains the sole preserve of the problem objects and API
calls do not hoard static variables.

I am not exactly sure what one would call this
characteristic: neither thread-safe nor reentrant are
appropriate, but nonetheless a behavioral guarantee
applies beyond what 'strtok' is able to offer.


Robbins and Robbins (p39) describe a small program
'wordaveragebad.c' (given below) that makes interleaved
calls to 'strtok'.  Each call to 'strtok' resets its
internal state, namely the location of the next token
to parse.  As a result, their demo program fails at
run-time (rather brittle behavior from a library, I
gotta say).  The fix is to rewrite the program using
'strtok_r' which additionally takes a user-provided
char* pointer to store the starting address for the
next parse.

'strtok' is thus often described as "non-reentrant",
meaning that the function should not be called again
before a previous call finishes.  Actually, Robbins and
Robbins prefer the term "thread-unsafe" -- perhaps
because the example cited does not use 'strtok' in a
strictly reentrant manner and yet remains buggy.
Conversely, 'strtok_r' can be described as
"thread-safe" (its manpage by implication, Robbins and
Robbins p38).


Robbins, Kay A and Steven Robbins.  2003 UNIX systems
  programming : communication, concurrency, and threads
  -- Second edition.  Prentice Hall PTR, Upper Saddle
  River, New Jersey, USA.  ISBN 0-13-042411-0.


If anybody is interested, 'wordaveragebad.c' shows the
incorrect use of 'strtok'.  And 'wordaverage.c' is a
correct program using 'strtok_r'.

Robbie Morrison
PhD student -- policy-oriented energy system simulation
Technical University of Berlin (TU-Berlin), Germany
University email (redirected) : address@hidden
Webmail (preferred)           : address@hidden
[from IMAP client]

reply via email to

[Prev in Thread] Current Thread [Next in Thread]