Hi Carl,
Thank you for putting efforts to boost the performance of the ratsnest.
The function is brought by an external library
(http://www.sintef.no/Projectweb/Geometry-Toolkits/TTL/), I am not sure
what is exactly inside. The expected output should be a Delaunay
triangulation of all nodes that are taken into account while computing
ratsnest.
The only issue I am aware of, is the function does not handle well empty
containers, but it should not be the case right now.
Now, when I looked again to the source code, RN_DATA is derived after
hed::Node class (include/ttl/halfedge/hetriang.h), which contains a
static field. Another thing is (I believe this is the main source of
troubles) static hed::Triangulation (include/ttl/halfedge/hetraits.h:73).
Sorry that I did not say about that before, but I have just discovered
that it is done that way. I will try to change it, but unfortunately
there are little chances that I manage to do that before Sunday.
Regards,
Orson
On 01/22/2014 06:08 PM, Carl Poirier wrote:
Maciej,
Can you summarize to me how the function "Triangulation::createDelaunay(
nodes.begin(), nodes.end() )" works, and what are the data structures
involved?
I believe there are some dependencies in there.
On Tue, Jan 21, 2014 at 4:05 PM, Cirilo Bernardo
<cirilo_berna...@yahoo.com <mailto:cirilo_berna...@yahoo.com>> wrote:
>________________________________
> From: Carl Poirier <carl.poirie...@gmail.com
<mailto:carl.poirie...@gmail.com>>
>To: Marco Serantoni <marco.serant...@gmail.com
<mailto:marco.serant...@gmail.com>>
>Cc: Kicad Developers <kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>>
>Sent: Wednesday, January 22, 2014 3:51 AM
>Subject: Re: [Kicad-developers] Net names and net codes
>
>
>
>There are some things in the code that don't like being
multithreaded. If I parallelize the for loop in
RN_DATA::Recalculate( int aNet ), I get a segfault. It does not
happen if I put a lock to the call updateNet( i ), but obviously
there is no increase in performance. I'm trying to find out what's
the problem now.
>
>
>
This sounds to me like data is being altered by different threads
and possibly there is some memory reallocation happening (growing
arrays, etc). Locks are only needed when there is contention
somewhere and of course locks should only be held for as short as
needed. Another pitfall with threading is that some variables may
need to be declared 'volatile' if they can be altered in another
thread while one function is executing. For example, let's say the
variable 'bool someX' can be altered in 2 threads; something like
this can happen:
1. FunctionA starts, and runs a loop while(!someX) { ... }
2. FunctionB sets 'someX' to 'true'
3. FunctionA continues to run the loop, which is not the intended
behavior
Of course similar things can happen when using shared memory and
forked processes.
Threading has other problems to watch out for - for example, are
there any static variables in functions? If so then you simply
cannot thread those functions without locks.
- Cirilo
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp