Threaded structure fields!

[srod]

Hi,

this is a coding question combined with a feature request (in the event that no one can see an easy way to solve my problem! )

At the moment I am battling with a problem which, if allowed to use api, would be easy to solve via a TLS (Thread Local Storage) index. However, I am confined to using 100% crossplatform code in this instance and would like to avoid conditional compilation to employ the equivalent of such indexes for Linux etc.

My problem would additionally be solved if it would be possible to nominate a field within a structure as being threaded! (And this would comprise my feature request!)

At this minute I see no way of resolving my problem using the Threaded variables introduced in PB 4.4 (as great and as useful as these are). Here's a brief outline of the situation :

• User calls my library to map a certain file into memory ... for his troubles, the user (client app) receives what I have termed an EC handle (similar to a device context) used to identify this mapping. Of course, this handle is a pointer to an internal structure.
• User may map as many files as he wishes and for each he receives a unique EC handle. There can thus be many valid EC handles in operation at once.
• Against each EC handle, the user can create multiple-threads. Each thread must have access to the underlying EC handle but also requires additional fields unique to the thread of execution in question.

It is the dynamic nature of the EC handles themselves together with the requirement that each such handle can store threaded data that would appear to rule out the use of PB's threaded variables. A single EC handle must be preserved across multiple threads; it is just that a single field within this handle needs to hold data unique to the thread of execution.

I cannot simply create the EC handles as threaded variables because the handles themselves would not be preserved across threads and there of course could be many such handles in use at any given time.

In terms of being crossplatform, the only 'solutions' (untested) I can think of are way too complex for my liking.

With these kind of things though I normally overlook the simplest solutions! Thought I'd therefore post this in the form of a coding question in the hope that someone can see what I cannot right now?

Thanks in advance for any suggestions.

Stephen.

[Marlin]

Maybe you could use such a principle:

Code: Select all

EnableExplicit

Structure ThreadDataStruct
  *EC_handle
  StringForThread.s
  String2ForThread.s
  LongForThread.l
EndStructure

Procedure myThreadProcedure(*pParams)
  ; do what supposed to be done
  
  FreeMemory(*pParams)
EndProcedure

Procedure.i StartThread(*pEC_handle, pString1.s, pString2.s, pLong.l)
  Protected *ThreadData
  
  *ThreadData = AllocateMemory(SizeOf(ThreadDataStruct))
  *ThreadData\EC_handle = *pEC_handle
  *ThreadData\StringForThread.s = pString1
  *ThreadData\String2ForThread.s = pString2
  *ThreadData\LongForThread.l = pLong
  ProcedureReturn CreateThread(@myThreadProcedure(), *ThreadData)
EndProcedure

If not, what did I miss in your question?

[srod]

Yes I have moved on to the idea of 'duplicate' handles which would seem to offer a solution to my problem and would equally appear to be what you are hinting at there. The duplication will be handled in a fashion which is transparent to the users in that they will know nothing about them. Each duplicate-threaded handle (if I may call them that) will point back to a structure which has to be shared amongst all duplicates and contains the additional fields required by each thread. Simple, obvious... doh!

This is a solution which effectively turns my initial attempts completely upside down in that my first attempts at solving this had the main EC handle trying to point to additional structures being fed from the multiple threads. There is just no way that I can see for PB (without api) to switch this portion of the handle depending upon the current thread etc. Well there is a way using threaded variables to construct a 'look-up' table but that is just messy.

This duplicate handle solution has resulted in me trashing about 1000 lines of code though.

Still, I think it to be worth it because I can currently see no reason why this should not work and rewriting all of the necessary code (rather than trying to patch the existing code) does give me the chance to find those unforseen problems!

Thanks for the reply.

[srod]

REMOVED.

[Fred]

may be using a structured threaded map/list ?

[srod]

Yes I thought about that Fred but there are other things in this program of mine which make such a solution 'tricky'. Very tricky!

I have overcome the problem with the duplicate handles - that is definitely the way forward in this instance. A lot of code to rewrite, but, well, sometimes you have to bite the bullet and get on with it!

Fred, do you think there may be a possibility, in addition to the new threaded variables (which I have put to very good use) that we can have an extension of this to wrap the TLS indexes? I know that there is an equivalent on Linux as Freak once pointed me towards the appropriate functions and presumably you have used these anyhow in the implementation of threaded variables. This would easily allow us to embed the equivalent of threaded variables within structures in such a way that the bulk of the structure could otherwise contain static fields (which do not change regardless of which thread accesses the structure). The equiavalent of the 4 TLS api functions would be great. PB wouldn't even need to worry about garbage collection as that responsibility would be on us to free any indexes created and so a TLS index would simply sit inside a regular integer variable etc.

Could be a useful addition I reckon.