Re: Toward a reentrant/thread safe parser and lexer

[CdeMills]

John W. Eaton wrote
> BTW, while making these changes, I noticed that Octave was already making
> nested calls to the parser.  The nested calls could happen when Octave
> processed callback functions through the readline event hook
> mechanism.  I'm not sure how this ever worked properly.  I suppose it
> worked in most cases because the callback would occur when Octave was
> waiting for input at the beginning of a parse, so the internal state
> of the parser was the same before and after the nested parse and
> things just happened to work out.  I guess we are lucky that it does
> not fail often...

Sharing variables within concurrent threads MAY fail if two threads try to
access and modify some var simultaneously. To trigger such issue, both
threads must be active on different processors at the same time. This is
most likely to occur if you put a lot of pressure on the CPU, i.e. have both
threads do a lot of access at the same time. If this is not the case and if
the number of accesses is low, this event will rarely occur, or fall in the
category "hardly reproducible".

The standard cure is to associate a lock with each shared variable, the
access patterns being:
read: get the lock - read - release the lock
write: get the lock - read - modify - write - release the lock

The time interval between getting the lock and releasing it should be short,
in order not to stall other waiting threads. A last detail: every variable
should have its own lock. With the access patterns, you avoid a second
thread reading the variable which is in fact gone to be overwritten shortly
after by a first thread.

Regards

Pascal




--
View this message in context: 
http://octave.1599824.n4.nabble.com/Toward-a-reentrant-thread-safe-parser-and-lexer-tp4650390p4650427.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.