1.程序开发中的注册表怎么解释？
2.线程池中空闲的线程处于什么状态？
3.ThreadX系列 | 最新v6.1.6版本在MDK中的移植方法
程序开发中的注册表怎么解释？
在程序开发中预定义出来的表就是注册表。
提供了一个 注册表， 这是一个预定义出来的表， 可以用来保存任何 C 代码想保存的 Lua 值。 这个表可以用有效伪索引 LUA_REGISTRYINDEX 来定位。 任何 C 库都可以在这张表里保存数据，尖峰对决源码 为了防止冲突，你需要特别小心的选择键名。 一般的用法是，你可以用一个包含你的库名的字符串做为键名， 或者取你自己 C 对象的地址，以轻量用户数据的形式做键， 还可以用你的代码创建出来的任意 Lua 对象做键。 关于变量名，字符串键名中以下划线加大写字母的名字被 Lua 保留。
注册表中的在线笔记 源码整数键用于引用机制 （）， 以及一些预定义的值。 因此，整数键不要用于别的目的。
当你创建了一个新的 Lua 状态机， 其中的注册表内就预定义好了几个值。 这些预定义值可以用整数索引到， 这些整数以常数形式定义在 lua.h 中。 有下列常数：
LUA_RIDX_MAINTHREAD: 注册表中这个索引下是状态机的主线程。 （主线程和状态机同时被创建出来。）
LUA_RIDX_GLOBALS: 注册表的这个索引下是全局环境。
在内部实现中，Lua 使用了 C 的 longjmp 机制来处理错误。 （如果你使用 C++ 编译，Lua 将换成异常； 细节请在源代码中搜索 LUAI_THROW。） 当 Lua 碰到任何错误 （比如内存分配错误、math库源码类型错误、语法错误、还有运行时错误） 它都会 抛出一个错误出去； 也就是调用一次长跳转。 在 保护环境 下， Lua 使用 setjmp 来设置一个恢复点； 任何发生的错误都会跳转到最近的一个恢复点。
如果错误发生在保护环境之外， Lua 会先调用 panic 函数 （） 然后调用 abort 来退出宿主程序。 你的 panic 函数只要不返回 （例如：长跳转到你在 Lua 外你自己设置的恢复点） 就可以不退出程序。
panic 函数以错误消息处理器（）的方式运行； 错误消息在栈顶。 不同的是，它不保证栈空间。 做任何压栈操作前，panic 函数都必须先检查是否有足够的空间 （）。
大多数 API 函数都有可能抛出错误， 例如在内存分配错误时就会抛出。wireshark源码分析 每个函数的文档都会注明它是否可能抛出错误。
在 C 函数内部，你可以通过调用 lua_error 来抛出错误。
线程池中空闲的线程处于什么状态？
一:阻塞状态,线程并没有销毁,也没有得到CPU时间片执行;
源码追踪:
for (;;) {
...
workQueue.take();
...
}
public E take()...{
...
while (count.get() == 0) { / /这里就是任务队列中的消息数量
notEmpty.await();
}
...
}
public final void await()...{
...
LockSupport.park(this);
...
}
继续往下:
public static void park(Object blocker) {
Thread t = Thread.currentThread();
setBlocker(t, blocker);
U.park(false, 0L);
setBlocker(t, null);
}
private static final sun.misc.Unsafe U = sun.misc.Unsafe.getUnsafe();
//线程调用该方法，线程将一直阻塞直到超时，或者是中断条件出现。
public native void park(boolean isAbsolute, long time);
上面就是java线程池中阻塞的源码追踪;
二.对比object的wait()方法:
@FastNative
public final native void wait(long timeout, int nanos) throws InterruptedException;
还有Thread的sleep() 方法:
@FastNative
private static native void sleep(Object lock, long millis, int nanos)throws...;
可见,线程池中使用的阻塞方式并不是Object中的wait(),也不是Thread.sleep() ;
这3个方法最终实现都是通过c&c++实现的native方法.
三.在<<Java虚拟机(第二版)>>中,对线程状态有以下介绍:
.4.3 状态转换
Java语言定义了5种线程状态，在任意一个时间点，一个线程只能有且只有其中的一种
状态，这5种状态分别如下。
1)新建（New）：创建后尚未启动的线程处于这种状态。
2)运行（Runable）：Runable包括了操作系统线程状态中的Running和Ready，也就是处于此
状态的线程有可能正在执行，也有可能正在等待着CPU为它分配执行时间。
3)无限期等待（Waiting）：处于这种状态的oschina ios源码线程不会被分配CPU执行时间，它们要等待被
其他线程显式地唤醒。以下方法会让线程陷入无限期的等待状态：
●没有设置Timeout参数的Object.wait（）方法。
●没有设置Timeout参数的Thread.join（）方法。
●LockSupport.park（）方法。
4)限期等待（Timed Waiting）：处于这种状态的线程也不会被分配CPU执行时间，不过无
须等待被其他线程显式地唤醒，在一定时间之后它们会由系统自动唤醒。以下方法会让线程
进入限期等待状态：
●Thread.sleep（）方法。
●设置了Timeout参数的Object.wait（）方法。
●设置了Timeout参数的Thread.join（）方法。
●LockSupport.parkNanos（）方法。
●LockSupport.parkUntil（）方法。
5)阻塞（Blocked）：线程被阻塞了，“阻塞状态”与“等待状态”的区别是：“阻塞状态”在等
待着获取到一个排他锁，这个事件将在另外一个线程放弃这个锁的时候发生；而“等待状
态”则是在等待一段时间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将
进入这种状态。
结束（Terminated）：已终止线程的线程状态，线程已经结束执行。
ThreadX系列 | 最新v6.1.6版本在MDK中的移植方法
本文分享了在MDK中移植ThreadX系列最新v6.1.6版本的方法，特别强调了更新过程及与之前的移植体验的比较。移植的开发板为小熊派IoT开发板，主控为STMLRCT6。首先，用户需要准备一份包含「正常使用printf串口输出的裸机工程」，推荐使用cubemx生成。
接着，从GitHub开源仓库获取ThreadX源码，将源码添加到MDK工程中。具体步骤包括创建threadX/common分组，将threadX/common/src下的所有c文件添加到此分组，以及新建threadX/ports分组，根据编译环境（例如使用AC5编译器）添加相应的.s文件。设置编译器为AC5，并添加头文件路径，以确保移植过程的顺利进行。
在移植过程中，用户可能会遇到ThreadX官方提供的底层适配文件tx_initialize_low_level.s，该文件中的函数用于处理器的底层初始化。然而，ThreadX在v6版本及其后续版本中对这个文件进行了修改，试图接管处理器的底层初始化，包括设置堆栈环境、重新定义向量表以及接管复位程序，这引起了一些争议。尽管ThreadX的意图可能是为了提供更全面的系统支持，但这种做法在某些方面可能并不合适，因为它直接接管了系统中断，而中断管理通常是操作系统的责任。尽管如此，移植工作仍需继续，用户可以通过创建自定义的适配文件来解决与原始文件的不兼容问题。
具体步骤包括复制tx_initialize_low_level.s文件，并创建自定义适配文件tx_initialize_low_level_bearpi.S，其中包含了对原有代码的修改以适应特定的移植需求。例如，修改与STM启动文件相关的代码，如设置时钟频率、初始化Systick定时器、处理堆栈环境等。在适配文件中，用户需要注释掉ThreadX定义的中断向量表和复位处理程序，并根据实际需求调整底层初始化函数。
此外，为了兼容现有代码，用户需要注释掉HAL库提供的中断服务函数，如PendSV和Systick中断服务函数。完成这些步骤后，用户可以编写应用代码，包括创建任务和启动内核。在main.c中包含ThreadX头文件，并在main函数中初始化内核，以完成整个移植过程。通过编译和下载，用户可以在串口终端观察到系统运行结果。
本文分享的移植过程提供了对最新ThreadX版本在特定环境中的应用指南，以及在遇到官方修改时的调整策略。虽然在某些方面存在争议，但通过适当的适配和调整，用户仍能成功地将ThreadX移植至其目标开发板，实现稳定且高效的操作系统功能。
