I read through the previous thread on new parallel programming features in XE7 & they slightly burst my bubble, having seen the Delphi sales-videos which show how easy it is to do parallel programming ... hey ho.

I can see a strong need to be thread-safe with parallel stuff, but please can people confirm the following:

I have a lengthy report-generation process. It takes as a parameter an EDB-Dataset, but this dataset is read-only. and the process simply iterates the dataset does work with the data it finds and then generates a report. It might close the dataset at the end or not.

I think this example _could_ work with the new XE7 parallel programming tools, without needing to be too careful about EDB-DB's, Sessions etc., as there is no interaction with them.

Is this correct?

Adam Brett wrote:

> I have a lengthy report-generation process. It takes as a parameter
> an EDB-Dataset, but this dataset is read-only. and the process simply
> iterates the dataset does work with the data it finds and then
> generates a report. It might close the dataset at the end or not.
>
> I think this example could work with the new XE7 parallel programming
> tools, without needing to be too careful about EDB-DB's, Sessions
> etc., as there is no interaction with them.

My thinking is that IF (big if) you can read your data into an in
memory structure for processing, then you could process it in parallel.
Reporting is an interesting one, as it often needs sequential operation
as it depends on the previous item to know where to start on a page,
for example.

But I don't think that you could parallelize the reading of the
database in the first place, as you are using threads, and therefore
need the sessions etc to be separate.

As I've said before, these are all things that you can do with
threading, and worker pools and tasks, but from the code you showed,
they aren't part of the "magic" Delphi threading solution. I think
they'd be your best bet for getting performance though.

--

Matthew Jones

Adam

>I think this example _could_ work with the new XE7 parallel programming tools, without needing to be too careful about EDB-DB's, Sessions etc., as there is no interaction with them.
>
>Is this correct?

I will, obviously, defer to Tim on this but my take is no way, never, over my (well preferably your) dead body etc

IF AND ONLY IF the thing you are reading is atomic in nature (eg boolean) then does this seem  to be safe. All of the discussions I've read on the embarcadero newsgroups, from people I trust, make the point that even reading can be perilous.

I have no idea how TParallel works but imagine the scenario your app goes through extracting the data from this "read only" database so asks for record 97 at the same time, in a parallel universe, it also asks for record 103. Do you have any idea what you'll end up with - I don't.

Stick with nice tried and tested threads

Roy Lambert

Roy Lambert wrote:

> Stick with nice tried and tested threads

That made me wonder what they actually propose it is used for. So I
watched https://www.youtube.com/watch?v=x8S5b0peu7U which starts with a
numeric calculation (50,000 tests), and the parallel one is faster. But
it does nothing to set up and close down.

More interesting is the TTask demo, since that is more realistic. A
task for each lookup might be sensible. But it also mentions thread
pools, which I mentioned way back. I suspect that the thread pool will
have a way to initialise the thread somehow, and that would be where
you put your session creation. Then the startup and shutdown is easy.


I'm not sure that learning this new system is that much better than
rolling your own, but a thread pool and list of operations to be done
is still the answer. I have a thread pool in one of my applications,
and the system starts by creating the list of tasks, then creates the
threads to run over it, and on completion they look for the next task
and if none they close down. The last thread then runs the combine task
which brings it all together. The new library looks "cool" but doesn't
give anything that hasn't been possible for years.


--

Matthew Jones

This sums it all up nicely, I think:

https://twitter.com/chronum/status/540437976103550976

--

Matthew Jones

Matthew


Took about 15 seconds to sink in - brilliant.

Roy Lambert

Matthew

>That made me wonder what they actually propose it is used for.

Fashion and marketing.

I don't have XE7 so I've only seen the presentation / video.

I'm old enough to be a cynic. Unless you have a task that really needs to be carried out in parallel (eg I have a background thread checking on alarms and if new emails have arrived and not been read, and another one that does the intensive database search rather than the quick filtering) an app isn't going to benefit from it - after all most modern PCs, even in business, spend most of their life having a nice sleep.

What would be really nice would be the ability to write something and test in the foreground and at runtime just go "right load and run this unit in the background" without having to mess with the thread creation etc. Maybe that's where embarcadero are heading.

Roy

Roy Lambert wrote:

Matthew

>>That made me wonder what they actually propose it is used for.<<

>Fashion and marketing.<

You're probably right.

I hear OmniThread is quite good for creating multi-threaded Delphi apps. It is free from http://otl.17slon.com/.
It is not listed as working with XE7 so you may need to build a package for it and test it out.

Barry

Barry wrote:

> I hear OmniThread is quite good for creating multi-threaded Delphi
> apps.

Indeed, I've pondered it, but the basic TThread is very capable too.
The main things are keeping things isolated, which isn't hard, but it
helps to know about the philosopher's tea party and the like which I
read about in a Tanenbaum book many years ago. Once you understand the
principles, using a global object with critical sections for
communication between threads works really nicely.

--

Matthew Jones

Barry


>I hear OmniThread is quite good for creating multi-threaded Delphi apps. It is free from http://otl.17slon.com/.
>It is not listed as working with XE7 so you may need to build a package for it and test it out.

One of the blogs I read suggested that TParallel was based on OmniThread


Roy