Page 1 of 2
[Implemented] Multiple string buffers?
Posted: Mon Mar 17, 2003 12:19 pm
by BackupUser
Restored from previous forum. Originally posted by Pupil.
I don't know what's planned on the issue with threads and string commands, so i just fire away. Would it be possible to somehow make some sort of scheme where you reserve different string buffer space for threads that you have running?
Posted: Mon Mar 17, 2003 1:15 pm
by BackupUser
Restored from previous forum. Originally posted by fred.
I have to see if it's possible, and how, but that's a good suggestion. May be with a 'ThreadSafe' flag at compile time.
Fred - AlphaSND
Posted: Mon Mar 17, 2003 1:50 pm
by BackupUser
Restored from previous forum. Originally posted by Pupil.
It would be absolutely great to have the ability to work with strings in threads, because in the current state you have to create your program so it either reserves the string handling exclusively for the time it takes to finish or you have to create your own string handling routines. If your using the first method you might get a lot of stalls in your program when several threads are waiting for another thread to finish it's string handling, the other method, well let's just say that it takes a lot of work to do simple things that you do so easily with the inbuild string commands..
How do you mean that the 'ThreadSafe' flag should work? Should it be at the top of the source or should it be specified when you issue the CreateThread() command or is it supposed to flag the Prodecures that are used in a thread?
I have some ideas about how it could work, but they're methods that's not exactly automated by the compiler and thus leaves it up to the programer to create his program after certain guidelines to make it work correctly. I also have to say that i'm not that experienced programer so the ideas that i have might not work satisfactory at all..
Posted: Mon Mar 17, 2003 2:21 pm
by BackupUser
Restored from previous forum. Originally posted by fred.
Ok, let's discuss about it. If the 'ThreadSafe' flags is put on (let's say in the compiler option window) we change the regular string handling with a new one, slower and bigger, but thread proof. So, firstly, the purebasic commands which use the string buffer should never access the string buffer directly like they actually do. That's not impossible to do, but need some time. So we now have independant string functions, which use a given string buffer, passed on the stack. Ok. Now, we can allocate a string buffer for each thread, and store them in a array, which hold the ThreadID and its associated string buffer.
The following case has to be handled:
Procedure Common()
EndProcedure
Procedure Thread()
Common()
EndProcedure
So it's easy to flag the Thread procedure at compile time, but it will not help as common() can be called by differents thread. So we need a method to retrieve the right stringbuffer depending of the current threadid. Something like PB_StringBase = GetThreadStringBuffer()... This would work if all commands which use the stringbuffer internally are rewritten as stated above.
If you have a different approach, it would be interresting. This one will be slow only by retrieving the right stringbuffer each time a string function is called, which could be really painful if many threads runs.
Fred - AlphaSND
Posted: Mon Mar 17, 2003 3:24 pm
by BackupUser
Restored from previous forum. Originally posted by freak.
Great plans...
I would prefer the 'compiler options' way.
Timo
Posted: Mon Mar 17, 2003 3:52 pm
by BackupUser
Restored from previous forum. Originally posted by Pupil.
You solution is quite a good one, with respect to program transparancy and ease of use, what i was thinking about is a bit more demanding on the programer on the other hand the speed would not decrease proportionally to the amount of threads running, but there would still be speed penalties for sure. Remember that these ideas is just from a layman and all experienced programers will probably find faults in my proposal.
Ok, now to some ideas of mine:
Here's some new commands that's needed:
Code: Select all
address.l = AllocateStringBuffer()
Allocate some fixed length buffer that is needed by
the string commands. Returns the address to the reserved
memory. If returned value is '0' the command has failed.
* note. this should just be a wraper command for the
GlobalAlloc_() API, could possibly be made with a
macro when that is finished.
FreeStringBuffer(address.l)
Free the reserved string buffer space.
UseStringBuffer(address.l)
Tell that this procedure should use 'address' as base address
for the string buffer.
* note. perhaps push this onto the stack as a normal variable
for later use with the string commands.
Changes that would have to be made:
* String Commands: The only thing that have to change in the string commands is that they have to take an extra argument i.e. the base address for the buffer.
* Compiler: The compiler have to be changed to automaticaly provide the base address to the string commands. If no address is defined in the procedure the default base address should be used.
Example of how it could look:
Code: Select all
Procedure Common(StringBuffer.l)
; This is somewhat the downside of this method, you have to provide the
; base address to the procedures that is called
UseStringBuffer(StringBuffer) ; Now all should be safe.
Endprocedure
Procedure Thread(foo.l)
; You can either reserve the string buffer inside
; or outside the thread, this time we do it inside.
address.l = AllocateStringBuffer()
UseStringBuffer(address) ; should test address first though.
Common(address)
FreeStringBuffer(address)
EndProcedure
Well that's just some thoughts of mine, might be good, might be bad, anyway thanks for your time!
Posted: Mon Mar 17, 2003 5:12 pm
by BackupUser
Restored from previous forum. Originally posted by fred.
Hum, why not, it's much easier to do
. Thanks to open my point of view and give some alternatives.
Fred - AlphaSND
Posted: Mon Mar 17, 2003 5:16 pm
by BackupUser
Restored from previous forum. Originally posted by freak.
> UseStringBuffer(address.l)
This command should then only set the buffer for the current thread! Otherwise, this would be useless (things could still be messed up by different threads.)
Timo
Posted: Mon Mar 17, 2003 5:59 pm
by BackupUser
Restored from previous forum. Originally posted by Pupil.
> This command should then only set the buffer for the current thread!
> Otherwise, this would be useless (things could still be messed up by different threads.)
Well that was the intended behaviour, if you see how the small example i've provided work you'll se that the address pointer is passed to each procedure that is called(only needed if the called procedure is manipulating strings) and each procedure calls the UseStringBuffer() command so the compiler knows what parameters to send to the string commands.
Posted: Mon Mar 17, 2003 6:22 pm
by BackupUser
Restored from previous forum. Originally posted by Pupil.
Originally posted by fred
Hum, why not, it's much easier to do
. Thanks to open my point of view and give some alternatives.
Fred - AlphaSND
It's always good to have a second opinion that enables you to see the problem from a different angle.
I have some ideas about how the compiler could implement the UseStringBuffer() command, if you're interested..
Posted: Mon Mar 17, 2003 8:24 pm
by BackupUser
Restored from previous forum. Originally posted by fred.
Ok, let's fire me a mail..
Fred - AlphaSND
Posted: Mon Mar 17, 2003 9:09 pm
by BackupUser
Restored from previous forum. Originally posted by freak.
Code: Select all
Procedure Common(StringBuffer.l)
; This is somewhat the downside of this method, you have to provide the
; base address to the procedures that is called
UseStringBuffer(StringBuffer) ; Now all should be safe.
; Do String operations here...
Endprocedure
That's the way it should work, right?
But what if, right between the UseStringBuffer() and the String operation, another thread calls UseStringBuffer() again?
See, the Buffer needs to be associated with the tread, otherways it can always be interrupted.
Just a thought, maybe i am just too stupid right now, to get the whole idea...
Timo
Posted: Mon Mar 17, 2003 9:32 pm
by BackupUser
Restored from previous forum. Originally posted by Pupil.
Originally posted by fred
Ok, let's fire me a mail..
Fred - AlphaSND
It's getting a bit late now, so most likely it'll be in your box sometime tomorrow after i've returned from work..
Posted: Mon Mar 17, 2003 9:47 pm
by BackupUser
Restored from previous forum. Originally posted by Pupil.
Originally posted by freak
That's the way it should work, right?
But what if, right between the UseStringBuffer() and the String operation, another thread calls UseStringBuffer() again?
See, the Buffer needs to be associated with the tread, otherways it can always be interrupted.
Just a thought, maybe i am just too stupid right now, to get the whole idea...
Timo
No need to worry it's been thought of and these kind of difficulties would not be able to happend as i see it. Think of this command in question more like a compiler directive than an actual library command..
I'll have to talk with Fred in more detail about this and then we all have to wait and see if something good can come out of it.
Posted: Mon Mar 17, 2003 9:53 pm
by BackupUser
Restored from previous forum. Originally posted by freak.
OK