I am trying to understand how the Least slack time (LST) algorithm works. What would be a possible approach to implement this using the posix threads. I referred to http://man7.org/linux/man-pages/man7/sched.7.html. I could see no scheduling macro which will support slack. I have googled it a bit and couldn't find a scheduler which does so. I know that the slack is the time from one threads execution time window which lie vacant after the thread completes execution and which can be preyed upon by a thread of same process which needs time. I know that it is used in industry like avionics displays. It would help if an approach can be given which already exists for posix threads.
Actually, LST is not local to a process but picks the thread where the expected completion time is closest to it's deadline. The problem with LST is that you need a (very good) guess of the thread's execution time, which is a complex problem. For that reason, one usually takes the EDF policy that has the same performance but does not need another parameter than the deadline.
Edit
To answer your additional question: since it is quite complex, I can give a sketch only. First: you can't predict a run time in general. There exists a famous result from theoretical computer science, that states one can not even predict whether a program will terminate at all.(see halting problem) However, by restricting recursion depth and bounding loops, one can determine a critical path (using results from graph theory) through the code. Now you need the execution time of any instruction of this path. However, this is far from being deterministic. Pipelining, caches, and out of order execution make the calculation harder. Of course, some of these effects may be avoided by e.g. switching off the cache. But then you get a much longer run time than needed. To summarize: with some measures you could provide an upper bound of the run time. If you want to reduce the overestimations, you have to consider lot of details.
There exist zillion of literature on that topic (google for WCET prediction) and even some good tools. However, without substantial effort, overestimation in the order of the run time itself is not considered as too bad.