I did a table that on start up would create the number of rows in the table based on the number of threads you have set.

when a thread started it would write "used" in that rows table cell it would then pass the row number to the define with your code you want to run in it. when the define had finished it would write free in that row. the thread control worked using table search for a free slot it looped until it found one it. this worked incredibly well the only issue was ubot never finished you had to use stop script command(I think this was because of the amount of writing to variables it was doing in a short space of time.

Limit multithreading to say max 10-15 threads? - (while running, do regular memory cleaning + when the bot starts, set a timer - maybe on load?- this is to shut the bot down after say 20 minutes.-the bot will check if this target has been reached or not - maybe via a separate thread...?)
Also perform 'close page' for 'new browsers' - at the end of code block.
After 20 minutes - save data + close bot + optionally before shut down ,let the main program 'open' a previously compiled bot ->which would just clean memory (os addin plugin?)- and restart the main bot and then shut itself down.
If adding delay helps in threads - how much and where should we add them?

I don't think that will help, because the problem is not with container, rather with UBot command "increment", "set variable", "add item to list",....

It definitely worked for me. I was having the exact same problem as described. Here is how I used it: -

when you increment the global thread count varable put it inside a 'thread safe container'. This will force all other threads to wait until the code within the container has executed. You also need to put reading values and writing values to global shared variables and lists within this container. This prevents multiple threads from reading and writing the same values. If you do this properly you can keep track of all the threads.

As an extra precaution, I put an if statement when I increment and decrement the thread counter to ensure that it does not exceed the max threads variable before I increment it and above zero before decrement it . These commands are done within a thread safe container. Here is an example of my thread control code: -

Limit multithreading to say max 10-15 threads? - (while running, do regular memory cleaning + when the bot starts, set a timer - maybe on load?- this is to shut the bot down after say 20 minutes.-the bot will check if this target has been reached or not - maybe via a separate thread...?)
Also perform 'close page' for 'new browsers' - at the end of code block.
After 20 minutes - save data + close bot + optionally before shut down ,let the main program 'open' a previously compiled bot ->which would just clean memory (os addin plugin?)- and restart the main bot and then shut itself down.
If adding delay helps in threads - how much and where should we add them?

While that would help overall with the performance of a bot - especially one running long term. It won't help with the threading issue because they die out incredibly fast. You may start with 10 threads and be down to 1 a minute later.

I don't get it?!! How do you guys sell bots if Multi threading is so badly implemented? Who would buy such bots? It doesn't make any sense..

I don't mean to offend anyone.. I consider myself a total beginner/learner of Ubot so I am just curious how is it possible to create stable multi threaded apps for sale with so many issues...

Thanks.

Well it wasn't really a problem when using the in browser commands since the thread count on average wouldn't be able to go higher than 5-10. But now that we are all using sockets our bots can now handle 100+. threads. Only problem now is what HelloInsomnia stated:

You may start with 10 threads and be down to 1 a minute later.

Hopefully UBotDev.com's plugin gets approved soon. I have had the privilege of testing it out and you can easily tell that the global variable problem is limiting the power of threaded bots.

It definitely worked for me. I was having the exact same problem as described. Here is how I used it: -

when you increment the global thread count varable put it inside a 'thread safe container'. This will force all other threads to wait until the code within the container has executed. You also need to put reading values and writing values to global shared variables and lists within this container. This prevents multiple threads from reading and writing the same values. If you do this properly you can keep track of all the threads.

As an extra precaution, I put an if statement when I increment and decrement the thread counter to ensure that it does not exceed the max threads variable before I increment it and above zero before decrement it . These commands are done within a thread safe container. Here is an example of my thread control code: -

Hopefully UBotDev.com's plugin gets approved soon. I have had the privilege of testing it out and you can easily tell that the global variable problem is limiting the power of threaded bots.

I can imagine that un-reviewed plugin popup is annoying.

Would love to see this plugin release soon.

Still waiting for approval. :/

Are single threaded applications obsolete? would like to know what the community has to say.

It's not obsolete, it's just that if you have a lot of "tasks" to process you can't wait 1 year (12 months) for single threaded bot to finish (because data is usually needed asap), instead you could use 12 threads/proxies and get the job done in one month, or even use 100 threads/proxies to complete all tasks in just 4 days. Would you prefer to wait one year?

So my opinion is that single threaded applications can still be used where speed/time is not an important factor...

No plugin key yet...I'm not sure what's taking so long...it's over a month and still no key. A few days ago they asked me if I still need the key plugin, and I said yes, else I wouldn't request it, but still no key till today. Not sure what is going on there but it looks like support is getting worse and worse.