Sam,
there is only the main thread and one wasm worker. No other code than the
one in the worker is accessing this particular pointer.
newSize is always greater than oldSize.
If I call the worker's code directly, i.e. work with the main thread only,
all is fine.
There is always a possibility that some of my code may not be thread-safe.
This is what I am examining now. As I am using my own allocMemPtr and
resizeMemPtr functions (plus two other functions), there are no other
calls in my code using malloc or realloc.
Using these to shield the memory calls seems to help somewhat (taken from
emmalloc.c, MALLOC_ACQUIRE, but renamed to avoid potential conflicts):
static volatile uint8_T threadLock = 0;
#define LOCK_ACQUIRE() while(__sync_lock_test_and_set(&threadLock , 1))
{while(threadLock){ /*nop*/ }}
#define LOCK_RELEASE() __sync_lock_release(&threadLock )
However, still there is corruption, and LOCK_ACQUIRE ends up in an infinite
loop in a simple malloc call.
It would be helpful to be able to have a watch function to keep an eye on a
specific memory portion to see when and by whom it gets changed.
@Shlomi: sorry, will do.
Cheers, Dieter
s...@google.com schrieb am Dienstag, 30. Mai 2023 um 21:59:31 UTC+2:
On Tue, May 30, 2023 at 12:10 PM 'Dieter Weidenbrück' via
emscripten-discuss <emscripte...@googlegroups.com> wrote:
Is newSize always greater than n ?
Are there other workers (or the main thread) that might be accessing `myP`
while this code is running?
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/emscripten-discuss/4b109935-8d70-4eef-af5c-bd4ff5b079e6n%40googlegroups.com.
