Benutzer:Rdiez/YouProbablyShouldWriteProperShutdownLogic - Versionsgeschichte

Rdiez: Weiterleitung nach Benutzer:Rdiez/PageRemoved erstellt

2015-03-22T19:01:23Z

Weiterleitung nach Benutzer:Rdiez/PageRemoved erstellt

Rdiez am 19. April 2013 um 18:08 Uhr

2013-04-19T18:08:37Z

Rdiez: Die Seite wurde neu angelegt: „= My embedded software never stops, so I don't need to implement a proper shutdown logic = If you allocate memory dynamically (with malloc), sooner or later you …“

2013-03-01T19:49:21Z

Die Seite wurde neu angelegt: „= My embedded software never stops, so I don't need to implement a proper shutdown logic = If you allocate memory dynamically (with malloc), sooner or later you …“

Neue Seite

= My embedded software never stops, so I don't need to implement a proper shutdown logic =

If you allocate memory dynamically (with malloc), sooner or later you will have to deal with some nasty [http://en.wikipedia.org/wiki/Memory_leak memory leak]. If your firmware can shutdown cleanly, you can dump all remaining allocations at the end. Otherwise, you'll have a hard time finding the leak.

It is very hard to take an existing software and retrofit a clean shutdown, especially if multiple threads are involved.

Implementing the shutdown logic from the first day will make you think properly about the lifetime of each service/task/component/thread. You will be glad if you need to reuse one them on another platform. Besides, if the need arises to reconfigure and restart a component on the fly, it will be much easier if the shutdown procedure has already been implemented.

In order to regularly exercise the termination logic, it's best to make it part of the firmware update procedure, so that the device shuts all components down before starting the new firmware. If the device can take a reset command from outside, that would be a good place to perform a software shutdown, right before the actual reset.

← Nächstältere Version		Version vom 19. April 2013, 18:08 Uhr
Zeile 1:		Zeile 1:
		+	{{BenutzerSeitenNichtVeraendernWarnung\|rdiez}}
		+
	= My embedded software never stops, so I don't need to implement a proper shutdown logic =		= My embedded software never stops, so I don't need to implement a proper shutdown logic =

@@ Zeile 1: / Zeile 1: @@
-{{BenutzerSeitenNichtVeraendernWarnung|rdiez}}
+#REDIRECT [[Benutzer:Rdiez/PageRemoved]]
-−
-= My embedded software never stops, so I don't need to implement a proper shutdown logic =
-−
-If you allocate memory dynamically (with malloc), sooner or later you will have to deal with some nasty [http://en.wikipedia.org/wiki/Memory_leak memory leak]. If your firmware can shutdown cleanly, you can dump all remaining allocations at the end. Otherwise, you'll have a hard time finding the leak.
-−
-It is very hard to take an existing software and retrofit a clean shutdown, especially if multiple threads are involved.
-−
-Implementing the shutdown logic from the first day will make you think properly about the lifetime of each service/task/component/thread. You will be glad if you need to reuse one them on another platform. Besides, if the need arises to reconfigure and restart a component on the fly, it will be much easier if the shutdown procedure has already been implemented.
-−
-In order to regularly exercise the termination logic, it's best to make it part of the firmware update procedure, so that the device shuts all components down before starting the new firmware. If the device can take a reset command from outside, that would be a good place to perform a software shutdown, right before the actual reset.