Thread-safety

Hi there,

I am attempting to write some code that is Multi-Threaded.

If I have a function named Thread1 say that has the line:

Call READF@(ptrDataP, i2HandleP, iNumBytesToReadP, iNumBytesReadP, i2ErrorL)

and another function named Thread2 say that has the line:

Call READF@(ptrDataP, i2HandleP, iNumBytesToReadP, iNumBytesReadP, i2ErrorL)

Where ptrDataP, i2HandleP, iNumBytesToReadP, iNumBytesReadP, i2ErrorL are different memory locations and with i2HandleP different handles for both, then if a Thread calls Thread1 and a different Thread calls Thread2, will there be a conflict?

I ask this because READF@ might be the same code called by each Thread and/or might not be Thread-safe and/or using 'locks'

I also need to know this for:

CURDIR@ MKDIR@ FILE_SIZE@ OPENF@ WRITEF@ READF@ CLOSEF@ Inquire

Regards Marz

The programmer must apply any required locks. FTN95 does not apply any locking automatically. So you must work out any possible interference and apply locking accordingly.

I am assuming that you are using FTN95 .NET.

No I am not using .NET

I merely wished to know if two separate threads simultaneously calling READF@ say, would cause a conflict. Perhaps in other words, assuming that the code for handling READF@ is in a single location, then without any 'locking' in the READF@ code, there arises the possibility of conflict, and in that case I AM asking whether or not routines such as READF@ use 'locking'. However, since I am not omniscient, there may be a way of overcoming this, perhaps something Salford/Silverfrost have done that would help me achieve my aim; but I find it difficult to ask directly since I do not know of it.

I am attempting to have multiple threads simultaneously read different files from a HDD/SDD.

Regards Marz

The only way I know to do threading with Win32 FTN95 is to use the Windows API to call CreateThread etc. but then I would not know how to attempt locking etc.

I wonder if you really mean 'threading' or do you mean 'multi processing'?

Quoted from PaulLaidler

I wonder if you really mean 'threading' or do you mean 'multi processing'?

Indeed.

In fact, the issues would be the same if, instead of different threads, different processes on the same computer or in a cluster attempted to gain access to a single file (or file record).

The usage of the word 'threads' (as if threading issues were more important than file/record-locking/sharing issues) in this forum thread is a red herring.