- About the invariants of a system.. - 2 Updates
- two's complement idea - 4 Updates
| aminer68@gmail.com: Jan 25 02:40PM -0800 Hello, About the invariants of a system.. I was just thinking about Petri nets , and i have studied more Petri nets, they are useful for parallel programming, and what i have noticed by studying them, is that there is two methods to prove that there is no deadlock in the system, there is the structural analysis with place invariants that you have to mathematically find, or you can use the reachability tree, but we have to notice that the structural analysis of Petri nets learns you more, because it permits you to prove that there is no deadlock in the system, and the place invariants are mathematically calculated by solving the following system of the given Petri net: Transpose(vector) * Incidence matrix = 0 As you will notice those place invariants calculations of the Petri nets look like Markov chains in mathematics, with there vector of probabilities and there transition matrix of probabilities, and you can, using markov chains mathematically calculate where the vector of probabilities will "stabilize", and it gives you a very important information, and you can do it by solving the following mathematical system: vector1 of probabilities * matrix transition of probabilities = vector1 of probabilities. Solving this system of equations is very important in economics and other fields, and you can notice that it is like calculating the invariants , because the invariant in the system above is the vector1 of probabilities, and this invariant, like in the invariants of the structural analysis of Petri nets, gives you a very important information about the system, like where market shares will stabilize that is calculated this way in economics. Read more my other thoughts: About reachability analysis of a Petri net.. As you have noticed in my Petri nets tutorial example (read below), i am analysing the liveness of the Petri net, because there is a rule that says: "If a Petri net is live, that means that it is deadlock-free." Because reachability analysis of a Petri net with Tina gives you the necessary information about boundedness and liveness of the Petri net. So if it gives you that the Petri net is "live" , so there is no deadlock in it. Read more: Tina and Partial order reduction techniques.. With the advancement of computer technology, highly concurrent systems are being developed. The verification of such systems is a challenging task, as their state space grows exponentially with the number of processes. Partial order reduction is an effective technique to address this problem. It relies on the observation that the effect of executing transitions concurrently is often independent of their ordering. Tina is using "partial-order" reduction techniques aimed at preventing combinatorial explosion, Read more here to notice it: http://projects.laas.fr/tina/papers/qest06.pdf About modelizations and detection of race conditions and deadlocks in parallel programming.. I have just taken further a look at the following project in Delphi called DelphiConcurrent by an engineer called Moualek Adlene from France: https://github.com/moualek-adlene/DelphiConcurrent/blob/master/DelphiConcurrent.pas And i have just taken a look at the following webpage of Dr Dobb's journal: Detecting Deadlocks in C++ Using a Locks Monitor https://www.drdobbs.com/detecting-deadlocks-in-c-using-a-locks-m/184416644 And i think that both of them are using technics that are not as good as analysing deadlocks with Petri Nets in parallel applications , for example the above two methods are only addressing locks or mutexes or reader-writer locks , but they are not addressing semaphores or event objects and such other synchronization objects, so they are not good, this is why i have written a tutorial that shows my methodology of analysing and detecting deadlocks in parallel applications with Petri Nets, my methodology is more sophisticated because it is a generalization and it modelizes with Petri Nets the broader range of synchronization objects, and in my tutorial i will add soon other synchronization objects, you have to look at it, here it is: https://sites.google.com/site/scalable68/how-to-analyse-parallel-applications-with-petri-nets You have to get the powerful Tina software to run my Petri Net examples inside my tutorial, here is the powerful Tina software: http://projects.laas.fr/tina/ Also to detect race conditions in parallel programming you have to take a look at the following new tutorial that uses the powerful Spin tool: https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html This is how you will get much more professional at detecting deadlocks and race conditions in parallel programming. Thank you, Amine Moulay Ramdane. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 25 11:11PM On Sat, 25 Jan 2020 14:40:02 -0800 (PST) > Hello, Goodbye. Petri nets are off topic, this is a C++ newsgroup. Go back to the newsgroups that you have already turned into a desert, and leave this one alone. We could also do without the racist white Arab stuff. |
| Ian Collins <ian-news@hotmail.com>: Jan 26 11:00AM +1300 On 26/01/2020 10:33, Bart wrote: > I've already said I can't tell how much bigger, less readable, less > productive it might have been to code like that, how many extra > functions etc, compared with just using the odd goto. The use of RAII generally makes the code smaller (we don't need to repeat the deallocation code for each allocation. As mentioned previously, most uses of goto in C kernel and driver code is what amounts to finally clauses, freeing stuff that may have been allocated before some error condition is detected. A classic example is this short function from the Linux kernel source: void vga_put(struct pci_dev *pdev, unsigned int rsrc) { struct vga_device *vgadev; unsigned long flags; /* The one who calls us should check for this, but lets be sure... */ if (pdev == NULL) pdev = vga_default_device(); if (pdev == NULL) return; spin_lock_irqsave(&vga_lock, flags); vgadev = vgadev_find(pdev); if (vgadev == NULL) goto bail; __vga_put(vgadev, rsrc); bail: spin_unlock_irqrestore(&vga_lock, flags); } (https://elixir.bootlin.com/linux/latest/source/drivers/gpu/vga/vgaarb.c) In C++, the lock would be managed so there's no need for a manual unlock and therefore no need for the "finally" block. -- Ian. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 25 10:22PM On Sat, 2020-01-25, Bart wrote: > The purpose of my mentioning Linux sources is that there are a range of > programming styles even in C: Linux kernel may be a prolific user of > gotos, DB is at the other end of the scale, and I would say extreme I haven't used them either. I don't think most people consider that extreme, except in that very literal sense. In one C project I was in, someone suggested we could use the "goto error" pattern as seen in the Linux kernel. Everyone accepted the idea, but I don't think we ever did it. That's the last time I heard about goto in real life, except jokingly. But I mostly work in C++ nowadays. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Bart <bc@freeuk.com>: Jan 25 10:23PM On 25/01/2020 22:00, Ian Collins wrote: > (https://elixir.bootlin.com/linux/latest/source/drivers/gpu/vga/vgaarb.c) > In C++, the lock would be managed so there's no need for a manual unlock > and therefore no need for the "finally" block. OK, but that's not a convincing example for that feature, as the goto can be trivially eliminated just by reversing the condition: if (vgadev != NULL) __vga_put(vgadev, rsrc); spin_unlock_irqrestore(&vga_lock, flags); (I wonder if some of this was machine translated? Either that or it was at some point more elabarate but the goto was left in. Or possibly, it was converted from ASM where you would see that pattern of jump.) > In C++, the lock would be managed so there's no need for a manual unlock > and therefore no need for the "finally" block. And also, regarding the 'lock' business, I don't know enough about what's going on here to know whether C++ style resource management (based on some identifiers going out of scope?) would be suitable here. Does 'vga_lock' even have local scope here? If global, how does C++ know when to do the unlock? In this case I'd have more confidence in the explicit C code. |
| Ian Collins <ian-news@hotmail.com>: Jan 26 11:46AM +1300 On 26/01/2020 11:23, Bart wrote: > if (vgadev != NULL) > __vga_put(vgadev, rsrc); > spin_unlock_irqrestore(&vga_lock, flags); It wasn't intended to be convincing, it just happened to be a short function with a "finally" block. There are other examples in that file with other resource releasing after the label. > (I wonder if some of this was machine translated? Either that or it was > at some point more elabarate but the goto was left in. Or possibly, it > was converted from ASM where you would see that pattern of jump.) It's a very common idiom in C driver code. > (based on some identifiers going out of scope?) would be suitable here. > Does 'vga_lock' even have local scope here? If global, how does C++ know > when to do the unlock? Well it's unlocked immediately before the closing brace which is where an RAII object would be destroyed. > In this case I'd have more confidence in the explicit C code. Until someone introduces an alternative return point and forgets to do the unlock... -- Ian. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment