| 02:14.17 | *** join/#stepcode hoiji (671b082a@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.42) |
| 02:29.02 | *** join/#stepcode infobot (~infobot@rikers.org) |
| 02:29.02 | *** topic/#stepcode is STEPcode - data exchange with the technologies of ISO10303 || http://stepcode.org || LOG http://ibot.rikers.org/%23stepcode/ |
| 02:29.32 | mpictor_ | the cl* libs can read the files, but just know the basics |
| 07:42.41 | *** join/#stepcode infobot (ibot@rikers.org) |
| 07:42.41 | *** topic/#stepcode is STEPcode - data exchange with the technologies of ISO10303 || http://stepcode.org || LOG http://ibot.rikers.org/%23stepcode/ |
| 12:30.21 | *** join/#stepcode mpictor (~mark@c-68-58-38-45.hsd1.in.comcast.net) |
| 15:43.33 | brlcad | https://github.com/stepcode/stepcode/blob/master/src/clstepcore/complexSupport.h#L261 |
| 15:46.07 | brlcad | hoiji: I'm not understanding what the problem actually is (why this is a problem to make threadsafe) |
| 15:46.39 | brlcad | if you have thread-safe readers and writers for that list class, you should be able to append to another list safely |
| 16:01.25 | hoiji | Ok for now say that I am trying to implement coarse grain locking. i.e. one fat lock per list. |
| 16:01.35 | hoiji | Say a thread (T1) want to append list B to A. |
| 16:01.50 | hoiji | Before appending them both A and B have different locks (call them mtxA and mtxB for now). |
| 16:02.00 | hoiji | During the appending I acquire both mtxA and mtxB. |
| 16:02.19 | hoiji | After appending them I get a new list (A'), This list should be protected by one lock. Say I choose mtxA to be the one to protect list A'. |
| 16:04.20 | hoiji | Now say when T1 was acquiring the lock mtxB (during appendList) another thread (T2) was also waiting for the lock mtxB as it wanted to do some operation on list B. |
| 16:04.49 | brlcad | so far sounds good |
| 16:07.09 | hoiji | After appending T1 would release mtxB. Now we have a situtation where for the same data we will have two mutexes. |
| 16:07.16 | hoiji | Say T1 now wants to modify some node of A'. Suppose it happens to be the very same node which T2 wanted to modify (through list B). |
| 16:08.42 | hoiji | It is possible that T1 and T2 will now work on the same node parallely. This might lead to unconsistent states !! |
| 16:09.33 | brlcad | eh, here's where you went off the deep end or you lost me in your final jump there |
| 16:10.02 | brlcad | how's what you describe not different than adding the same "node" to two different lists regardless of list appending |
| 16:11.07 | brlcad | if you're keeping identical node references in multiple lists, that's a problem completely independent of an append action |
| 16:12.49 | hoiji | No no I wasnt talking about identical node reference |
| 16:12.50 | brlcad | that said, I don't see how this is a list problem -- list A with (A1,A2,A3) and list B with (B1, B2) appended to list A with (A1,A2,A3,B1,B2) and list B with (B1,B2) seems perfectly reasonable |
| 16:13.49 | brlcad | if you have a thread safety problem with T1 and T2 accessing B1 simultaneously, you have that potential problem regardless of lists and appending data |
| 16:14.35 | brlcad | mtxA and mtxB should be ensuring the integrity of the LIST being managed |
| 16:16.28 | hoiji | The nodes are designed in such a manner that they can be a part of only one list (i.e they have only one next pointer and one prev pointer) |
| 16:16.51 | brlcad | like if you have list A (A1,A2,A3) and list B (B1,B2) and list C (C1), and T1 appends B to A and T2 appends C to A simultaneously, do you end up with A (A1,A2,A3,B1,B2,C1) -- or some permutation -- or do you ever end up with less than six elements! |
| 16:17.37 | brlcad | if the nodes are designed that way, then after append you should have ended up with (A1,A2,A3,A4,A5) |
| 16:17.47 | brlcad | i.e., you had to deep copy the node being appended |
| 16:18.14 | brlcad | otherwise appendList would be failing that design |
| 16:19.00 | hoiji | Ok as of now it was only doing A3->next = B1 and B1->prev = A3 |
| 16:20.08 | hoiji | i.e here https://github.com/stepcode/stepcode/blob/master/src/clstepcore/multlist.cc#L100 |
| 16:21.59 | hoiji | Would it be fine If change the semantics of appendList from doing simple pointer manipulation (as stated above) to deep copy? |
| 16:22.16 | hoiji | ^If I change |
| 16:24.48 | hoiji | Also if you are going through the above code dont get confused by the name MultList (or its superclass EntList). They act as nodes in this context |
| 17:31.44 | *** join/#stepcode infobot (ibot@rikers.org) |
| 17:31.44 | *** topic/#stepcode is STEPcode - data exchange with the technologies of ISO10303 || http://stepcode.org || LOG http://ibot.rikers.org/%23stepcode/ |