精华内容
下载资源
问答
  • 因此在常见异步/并行任务执行上,会遭遇到比普通javase程序更多麻烦。  典型例子,在javase,jdk1.5后就引入了java.util.concurrent包,提供Executor这个非常好用框架,完美满足...


        在application server下,比如常见的weblogic,glassfish,jboss等,由于javaee规范的要求,一般不容许直接启动线程。因此在常见的异步/并行任务执行上,会遭遇到比普通javase程序更多的麻烦。

        典型例子,在javase中,jdk1.5后就引入了java.util.concurrent包,提供Executor这个非常好用的框架,完美的满足一下典型需求:

        1. 同步变异步
            请求进来后,将请求封装为task,交给Executor执行,原线程可以立即返回
        2. 并行执行
            请求进来后,将请求拆分为若干个task,例如下发短信,有100个收件人就可以按照每个收件人一个task来执行,这样可以通过Executor来并行执行这些请求,远比循环执行要快的多。

        3. 等待任务结束
            有时有要求调用线程必须等待所有任务完成后再继续运行的需要,此外还有超时等细节设置要求。

        而在application server,为了避开自己启动线程的弊端,只好通过其他的方式来完成类似的功能。

        目前我们的项目开发中主要有三种实现方式:

        1. jms queue

            通过jms来实现异步和并发,然后自己通过编码方式完成调用线程等待所有任务执行成功。

            这个方案比较通用,因为jms是javaee的标准,所有的application server上都支持。因此天然具有跨application server的能力。

            缺点就比较多了,首先jms是需要实现串行化的,因此对task是有要求,不能串行化的类是不能传递的。另外串行化的性能损失比较大,造成性能和稳定性问题,这个在大压力下比较突出,基本我们目前在考虑放弃这个方案,而且逐步将原有的实现替换掉。
            这个方案还有另外一个缺点,配置麻烦,维护困难:需要创建jsm queque, connection factory, MDB等,如果系统中使用的多了,配置起来很罗嗦,修改时容许出错。

        2. commonj work manager

            这个是weblogic和WebSphere上支持的一个很实用的解决方案,个人感觉使用上非常舒服,配置简单,只要在weblogic-ejb-jar.xml中间中简单配置:

        < work-manager >
            
    < name > wm/taskDistributionWorkManager </ name >
            
    < min-threads-constraint >
                
    < name > minthreads </ name >
                
    < count > 1 </ count >
            
    </ min-threads-constraint >
            
    < max-threads-constraint >
                
    < name > maxthreads </ name >
                
    < count > 100 </ count >
            
    </ max-threads-constraint >
        
    </ work-manager >


            使用时用jdni lookup到就可以使用了。功能和使用方式和executor框架很类似,同样提供future,而且提供一个非常实用的waitAll()方法论支持等待任务完成。

            这个方案的性能非常好,和jms相比提升极大,运行也稳定。缺点就是不是标准,只有weblogic和WebSphere执行,在glassfish,jboss上无法使用。

        3. JCA work manager

            这个是JCA标准了,glassfish,jboss都支持的,和commonj work manager很像,但是,很遗憾的是没有future的支持,而且也没有类似的waitAll()方法,只能自己编码实现。
            spring为glassfish提供了一个工具类"org.springframework.jca.work.WorkManagerTaskExecutor",简化了JCA work manager的使用。

            JCA work manager的性能和稳定性都还不错,对比jms要好的多。

        从目前我们项目的使用经验上看,jms是准备要被淘汰的了(其实我是一直对jms不感冒的,尤其是在有性能要求的地方,想不出用jms的理由)。目前项目要求同时支持weblogic和glassfish,因此commonj work manager和JCA work manager刚好对应于weblogic和glassfish平台。实际使用中,是在这两个work manager上封装了一个通用的接口,然后再有commonj work manager和JCA work manager两个实现,在运行时通过判断平台来自动选择注入其中的一个。

    展开全文
  • 1.在uc/os操作系统设计串口编程时,由于ISR和多个任务并发执行,情况比较复杂。尤其是接收状态为被动状态时,只能靠串行口中断来接收数据。 2.在进行串行通信时,双方遵循相同通信协议。由于波特率不变,因此...
    UART0串口编程之在UC/OS—II中遭遇的危机
    一.潜在的危机

    1.在uc/os操作系统中设计串口编程时,由于ISR和多个任务并发执行,情况比较复杂。尤其是接收状态为被动状态时,只能靠串行口中断来接收数据。
    2.在进行串行通信时,双方遵循相同的通信协议。由于波特率不变,因此相邻两次串口中断的间隔时间基本固定。
    3.在以下两种情况时会使接收过程出现错误:
    (1)第一种情况是系统关中断的最长时间大于相邻两次串行接收中断的间隔时间,这时将可能导致遗漏一次中断,造成数据丢失。
    (2)实时操作系统内核的关中断的最长时间是已知的,通常很短,它不是问题关键。
    (3)系统关中断的最长时间往往是由用户软件造成的,例如:我们编写的中断服务函数过于复杂,导致系统为了处理中断服务函数而导致关中断时间过长。
    (4)第二种情况是在串口程序正在运行期间有一个比它优先级更高的中断程序中断了串口程序。从而造成数据丢失。
    (5)在这里提一个概念:把不能响应串口接收中断的这段时间称为“死区”。因此解决问题的关键是:死区时间不能比相邻两次串口中断的间隔时间长。
    二.如何解决危机
    l  任务在访问比较耗时的共享资源时不要采用关中断的方式(改成互斥信号量)。
    l  ISR要尽可能简短,将可以剥离的工作转交关联任务去完成。
    (此处的设计方式和Linux中把中断分为上半部分,和下半部分的原理有着同工异曲的含义)
    采用上面的方法来缩短死区时间。
    另一中方法是:
    加长相邻两次串口接收中断的间隔时间。
    l  方法一:降低波特率,这个方法简单,但因此也导致通信效率的下将。其次,一般在进行串口编程时,波特率一般是固定的。因此此方法一般不太适用。
    l  方法二:在波特率不变的情况下减少中断次数,达到加长相邻两次串口接收中断间隔时间的效果。
    ARM芯片的串口具有16字节的缓冲区,可以设置每接收1,4,8,14字节产生一次中断。如果设置每接收8字节中断一次,则比1字节中断一次要延长8倍的中断间隔时间。
    Tiger-John说明:
    l  在使用有数据缓冲功能的串口编程后,比较容易满足相邻两次串口接收中断的间隔时间大于死区时间的条件,但仍然存在潜在的危险。
    想要可靠的避免这场危机:必须要满足以下条件
    (1)相邻两次串口接收中断的间隔时间必须大于系统死区时间
    (2)接收缓冲区的空闲时间必须足够存放在“死区”时间内接收到的新数据。
     若设置每接收8字节中断一次,则空闲空间也为8字节。由于死区时间比中断间隔时间短,故接收的新数据必然少于8字节,才不会出现数据丢失现象。
    即在满足中断间隔时间大于“死区”时间的前提下,将中断条件设置为接收缓冲区的1/2,则死区时间接近中断间隔时间,接收过程是可靠的。
    展开全文
  • 1.在uc/os操作系统设计串口编程时,由于ISR和多个任务并发执行,情况比较复杂。尤其是接收状态为被动状态时,只能靠串行口中断来接收数据。 2.在进行串行通信时,双方遵循相同通信协议。由于波特率不变,因此...

    一.潜在的危机

    1.在uc/os操作系统中设计串口编程时,由于ISR和多个任务并发执行,情况比较复杂。尤其是接收状态为被动状态时,只能靠串行口中断来接收数据

    2.在进行串行通信时,双方遵循相同的通信协议。由于波特率不变,因此相邻两次串口中断的间隔时间基本固定。

    3.在以下两种情况时会使接收过程出现错误:

    Ø  第一种情况是系统关中断的最长时间大于相邻两次串行接收中断的间隔时间,这时将可能导致遗漏一次中断,造成数据丢失。

    ²  实时操作系统内核的关中断的最长时间是已知的,通常很短,它不是问题关键。

    ²  系统关中断的最长时间往往是由用户软件造成的,例如:我们编写的中断服务函数过于复杂,导致系统为了处理中断服务函数而导致关中断时间过长。

    Ø  第二种情况是在串口程序正在运行期间有一个比它优先级更高的中断程序中断了串口程序。从而造成数据丢失。

    ²  在这里提一个概念:把不能响应串口接收中断的这段时间称为“死区”。

    ²  因此解决问题的关键是:死区时间不能比相邻两次串口中断的间隔时间长。

    二.如何解决危机

    l  任务在访问比较耗时的共享资源时不要采用关中断的方式(改成互斥信号量)。

    l  ISR要尽可能简短,将可以剥离的工作转交关联任务去完成。

    (此处的设计方式和Linux中把中断分为上半部分,和下半部分的原理有着同工异曲的含义)

    采用上面的方法来缩短死区时间。

    另一中方法是:

    加长相邻两次串口接收中断的间隔时间。

    l  方法一:降低波特率,这个方法简单,但因此也导致通信效率的下将。其次,一般在进行串口编程时,波特率一般是固定的。因此此方法一般不太适用。

    l  方法二:在波特率不变的情况下减少中断次数,达到加长相邻两次串口接收中断间隔时间的效果。

    ARM芯片的串口具有16字节的缓冲区,可以设置每接收14814字节产生一次中断。如果设置每接收8字节中断一次,则比1字节中断一次要延长8倍的中断间隔时间。

    Tiger-John说明:

    l  在使用有数据缓冲功能的串口编程后,比较容易满足相邻两次串口接收中断的间隔时间大于死区时间的条件,但仍然存在潜在的危险。

    想要可靠的避免这场危机:必须要满足以下条件

    ²  相邻两次串口接收中断的间隔时间必须大于系统死区时间

    ²  接收缓冲区的空闲时间必须足够存放在“死区”时间内接收到的新数据。

    < 若设置每接收8字节中断一次,则空闲空间也为8字节。由于死区时间比中断间隔时间短,故接收的新数据必然少于8字节,才不会出现数据丢失现象。

    即在满足中断间隔时间大于“死区”时间的前提下,将中断条件设置为接收缓冲区的1/2,则死区时间接近中断间隔时间,接收过程是可靠的。

    展开全文
  • 1.在uc/os操作系统设计串口编程时,由于ISR和多个任务并发执行,情况比较复杂。尤其是接收状态为被动状态时,只能靠串行口中断来接收数据。 2.在进行串行通信时,双方遵循相同通信协议。由于波特率不变,因此...

    一.潜在的危机

    1.在uc/os操作系统中设计串口编程时,由于ISR和多个任务并发执行,情况比较复杂。尤其是接收状态为被动状态时,只能靠串行口中断来接收数据。

    2.在进行串行通信时,双方遵循相同的通信协议。由于波特率不变,因此相邻两次串口中断的间隔时间基本固定。

    3.在以下两种情况时会使接收过程出现错误:

    ?  第一种情况是系统关中断的最长时间大于相邻两次串行接收中断的间隔时间,这时将可能导致遗漏一次中断,造成数据丢失。

    2  实时操作系统内核的关中断的最长时间是已知的,通常很短,它不是问题关键。

    2  系统关中断的最长时间往往是由用户软件造成的,例如:我们编写的中断服务函数过于复杂,导致系统为了处理中断服务函数而导致关中断时间过长。

    ?  第二种情况是在串口程序正在运行期间有一个比它优先级更高的中断程序中断了串口程序。从而造成数据丢失。

    2  在这里提一个概念:把不能响应串口接收中断的这段时间称为“死区”。

    2  因此解决问题的关键是:死区时间不能比相邻两次串口中断的间隔时间长。

    二.如何解决危机

    l  任务在访问比较耗时的共享资源时不要采用关中断的方式(改成互斥信号量)。

    l  ISR要尽可能简短,将可以剥离的工作转交关联任务去完成。

    (此处的设计方式和Linux中把中断分为上半部分,和下半部分的原理有着同工异曲的含义)

    采用上面的方法来缩短死区时间。

    另一中方法是:

    加长相邻两次串口接收中断的间隔时间。

    l  方法一:降低波特率,这个方法简单,但因此也导致通信效率的下将。其次,一般在进行串口编程时,波特率一般是固定的。因此此方法一般不太适用。

    l  方法二:在波特率不变的情况下减少中断次数,达到加长相邻两次串口接收中断间隔时间的效果。

    ARM芯片的串口具有16字节的缓冲区,可以设置每接收1,4,8,14字节产生一次中断。如果设置每接收8字节中断一次,则比1字节中断一次要延长8倍的中断间隔时间。

    Tiger-John说明:

    l  在使用有数据缓冲功能的串口编程后,比较容易满足相邻两次串口接收中断的间隔时间大于死区时间的条件,但仍然存在潜在的危险。

    想要可靠的避免这场危机:必须要满足以下条件

    2  相邻两次串口接收中断的间隔时间必须大于系统死区时间

    2  接收缓冲区的空闲时间必须足够存放在“死区”时间内接收到的新数据。

    < 若设置每接收8字节中断一次,则空闲空间也为8字节。由于死区时间比中断间隔时间短,故接收的新数据必然少于8字节,才不会出现数据丢失现象。

    即在满足中断间隔时间大于“死区”时间的前提下,将中断条件设置为接收缓冲区的1/2,则死区时间接近中断间隔时间,接收过程是可靠的。

    展开全文
  • 吴恩达认为,通过深度学习模拟大脑,未来AI能够比人类更快地完成精神层面的任务。也有研究人员认为,应从大自然寻找灵感,让AI建立关于世界“心理模型”。 现在,我们已经将AI技术应用在自动驾驶和医疗上,...
  • Servlet 3中的异步处理

    2019-06-16 20:42:00
    有人可能会质疑,既然都有多线程了,还需要异步处理请求吗?答案是肯定的,因为如果一个任务处理时间相当长,那么Servlet...异步特性可以帮助应用节省容器中的线程,特别适合执行时间长而且用户需要得到结果的任务,...
  • Quartus中的打印设置

    2019-10-05 06:43:25
    昨天在使用quartus时候无意不知道修改了哪个设置,只要一打开.bdf文件,页面就会弹出 “在您可以执行与打印机有关的任务(例如页面设置或打印一个文档)之前,您必须已经安装打印机。您想现在安装打印机吗?”...
  • 我们研究中的管理人员设计了围绕技术相互依赖和协调的政策,并不是最有效地管理技术,而是以与职业结构和行业限制相一致的方式来管理工作和工人。 我们讨论了我们的发现对组织工作理论的意义。
  • 遭遇MSN病毒W32.Bropia

    2005-02-03 10:38:00
    有个朋友突然向我发送new_webcam.pif文件, 我接收后打开它, 在打开过程, Messenger又向我发送LOL.scr文件, 我询问对方是什么东西, 没有回复, new_webcam.pif文件打开速度比较慢,好像在后台执行什么任务,...
  • SQL 注入法挂马后,数据库中的表会被搞的乱七八糟,添加到字段的内容会被做为脚本执行,打开页面时,会显示网页被挂马。有以下几种方法可以处理这种情况:第一、执行脚本,清除注入内容这种时候,一般需要连接到...
  • 1.遭遇线程池套娃 1.schduler线程池提交TimedSupervisorTask线程任务 2.TimedSupervisorTask 向heartbeatExecutor线程池 提交HeartbeatThread线程任务 总结:线程池里线程向另一个线程池提交线程,嗯套娃 2.源...
  • 近日,美国空军声称,12架“猛禽”执行从夏威夷飞往日本的任务中,当途经国际日期变更线时,飞机上全球定位系统纷纷失灵,多个电脑系统发生崩溃,多次重启均告失败。飞行员们再也无法正确辨识战机位置、飞行高度...
  • 投稿全

    2007-04-27 11:02:56
    最近投了两篇搞子《论国内ERP产品稳定性》与《中国软件开发模式遭遇开发瓶颈》,全了,很高兴等发表后将链接发上来《中国软件开发模式遭遇开发瓶颈》(原名:ERP开发模式-任务的下达、执行与监督):...
  • ecplise ant 中文问题

    千次阅读 2010-08-10 17:45:00
    下午遭遇了eclipse自带ant跑时候编译到一半失去响应问题,但是如果使用命令执行任务一切ok。 Google 时发现有人说ecplise和ant集成,有中文乱码问题。会造成ant执行停止。 对比后发现,的确是...
  • 执行任务的过程,他遭遇到了一位蒙面黑衣人阻挠,这个人非常厉害,在过去他已经成功破坏了从001到006六位特工任务。那么007能否战胜蒙面黑衣人,完成这个事关国家未来命运任务呢?http://ike.126.com 片...
  • 对线程模型批评

    千次阅读 2012-07-04 16:26:09
    1997年,NASA 的“火星探路者”号在执行任务的途中遭遇了严重的时序异常(参见 “What really happend on Mars“,注目 follow-up 中的现身说法),无法发回探测数据。如果不是 NASA 远程刷新了程序,它的结局就...
  • 多线程模型是主流的并发编程模型。...1997年,NASA 的“火星探路者”号在执行任务的途中遭遇了严重的时序异常(参见 “What really happend on Mars“,注目 follow-up 中的现身说法),无法发回探测...
  • 1997年,NASA 的“火星探路者”号在执行任务的途中遭遇了严重的时序异常(参见 “What really happend on Mars“,注目 follow-up 中的现身说法),无法发回探测数据。如果不是 NASA 远程刷新了程序,它的结局就只能...
  • 通常情况下,你将要运行parsnp,遭遇和外延任务。 请参考以开始使用。 如果您使用此软件,请引用: Berbel Caban A,Pak TR,Obla A等。 基因组医学2020年11月16日; 12 (1):96。 PMID: doi:10.1186 / s...
  • ZendFramework中文文档

    2011-03-22 10:11:12
    在PHP Session 中的缺省持久(Persistence) 3.1.3.2. 实现订制存储 3.1.4. 使用Zend_Auth 3.2. 数据库表认证 3.2.1. 简介 3.2.2. 高级使用:持久一个 DbTable 结果对象 3.2.3. 高级用法示例 3.3. 摘要式...
  • 韩剧《城市猎人》

    2013-03-18 15:51:00
    特种部队中的精英,组成队伍,被祖国派去他国执行刺杀任务,完成任务返回到自己国家时,却意外在自己国内遭遇埋伏,一人(K)幸存外,其他人全部死亡。 K的眼中满含仇恨,他要为死去的兄弟们报仇,还记得执行任务...
  • 关于思想辩论首先出现在口头表达情况下,即关于旨在意识到要执行的任务和表征该任务的指示行动。 为了评估其效果,我们将从Zerai(2009)实验获取数据,并在结果与遭遇得分之间进行三角测量,定量数据...
  • 我们可能会遭遇性能问题,即使优化了代码,程序也依然有可能运行很慢,从而无法满足我们对执行速度要求,目前计算机,其cpu核心数越来越多,于是,我们可以考虑通过平行计算来提升性能,能不能把代码总计算...
  • Java终止或暂停线程

    千次阅读 2018-06-24 21:00:03
    线程执行任务完毕,正常退出;  2.线程遭遇异常,释放所占用锁,并退出;  3.线程调用stop()方法,强制终止线程;  4.线程使用interrupt方法中断线程.  本文章主要讨论使用stop方法和interrupt...
  • 1.在uc/os操作系统设计串口编程时,由于ISR和多个任务并发执行,情况比较复杂。尤其是接收状态为被动状态时,只能靠串行口中断来接收数据。 2.在进行串行通信时,双方遵循相同通信协议。由于波特率不变,因此...
  • UECMS 5.2.rar

    2019-05-27 11:58:38
    7、网页防篡改系统,系统集成自主开发网页防篡改程序,一旦web服务器中的页面遭到破坏,系统会自动将数据修复,保证网站的安全性; 8、网站通行证,提供同步登录、退出、注册等相关接口,可以实现用户使用一个账号...
  • 1)7月17日,美国加州圣贝纳迪诺,消防部门在执行一次高速公路灭火任务时在危险空域遭遇了5架相互追逐无人机,导致消防直升机无法正常作业并被迫提前返航。相关官员事后表示,这次意外至少造成了灭火工作20分钟...

空空如也

空空如也

1 2 3
收藏数 42
精华内容 16
关键字:

执行任务中的遭遇